Skills, prompts and MCP

Beyond provider routing, Nexus Composer also manages Codex’s skills, prompts, and MCP servers, and logs local usage with estimated cost.

Skills, prompts and MCP servers are Codex’s own features, so this page is specific to Codex — the agent Composer supports today. More agents are being added, and each brings its own tooling.

Skills

Skills are packaged instructions Codex loads for a task.

A skill is code from someone else

Discovery reaches third-party repositories, so treat installing a skill like adding a dependency: check who publishes it, prefer sources your organisation already approves, and clear it with your security team before using one on work that touches production systems.

1. Open Skills and choose Discover Skills.
2. Search your configured repositories, or skills.sh.
3. Read the description and check the source.
4. Choose Install, then restart or refresh Codex if needed.

The badge under each name is the source repository — that is the part to read before Install.

Prompts

1. Open Prompts and choose Add Prompt.
2. Give it a clear name and, optionally, a description.
3. Add the prompt content and save.
4. Enable the prompts you want Codex to use.

Saving adds the prompt; enabling it on the list is a separate step.

MCP servers

MCP servers give Codex tools — file access, search, an internal API — granting whatever the server can reach.

An MCP server runs with your access

A local server executes a command on your machine under your account. Add servers you can account for, and keep credentials in environment variables or your organisation’s approved secret store — never inline in shared configuration or a screenshot.

1. Open MCP and choose Add MCP.
2. Enter a unique identifier and a display name.
3. Choose which applications should use it.
4. Configure it with the wizard, or by pasting JSON or TOML.
5. Validate the command or URL, save, and restart the target client if needed.

For a local stdio server, the command it runs — npx, uvx or similar — must be installed and on the PATH Composer itself uses, not necessarily your interactive shell’s PATH.

The presets fill the form for a known server; Custom is the blank one. Read the JSON before saving — it is the command that will run.

Usage statistics

Settings → Usage Statistics records completed AI requests Composer routed. Each entry can show provider, model, input/output tokens, cache reads/creation, success or failure, time to first token, end-to-end duration, prefill/decode throughput, estimated cost, and the request’s source and kind. Filter by time range, provider, model, application, request source, and user where applicable.

One request is tied to the provider selected for it; switching providers doesn’t duplicate the request or its record. Only completed requests appear, and opening Composer creates none — an empty view usually means no traffic matches the filters.

Local statistics are not the whole picture

This view is Composer’s own record of traffic it routed, and its cost column is an estimate. The console’s Billing usage page is the tenant-wide record, but it is metering too — requests and tokens by model, not an invoice or a GPU/storage cost statement. Neither view describes how OneNexus handles request content server-side: prompts and outputs are not retained. See Pilot & security.

Next steps

• Nexus Composer — install, connect, and route a client.
• Composer troubleshooting — when a skill, server or route does not behave.