Direct answer

Add an MCP Server to Codex

Run one command: codex mcp add zambo --url https://zambo.dev/mcp. Or add a [mcp_servers.zambo] block with that url to ~/.codex/config.toml by hand. Confirm it with codex mcp list, start a fresh session, and Codex has the server: 153 tools in total, 35 on the default surface, memory shared with your other AIs, and a verifiable receipt for tool calls routed through Zambo. No API key, no local process, nothing to install.

Updated October 20, 2026.

Why add an MCP server to Codex at all

Codex works in your terminal and your repo: reading code, making edits, running commands, and reporting back. Its world, by default, is the machine it runs on. An MCP server widens that world. MCP, the Model Context Protocol, is the shared wiring that lets a client like Codex offer outside tools to the model as named, callable tools inside a session. Add Zambo and a Codex run can pull a live price instead of quoting a remembered one, audit a public page, search for demand signals, save a fact that Claude or Cursor can recall tomorrow, and file a checkable record of the steps that carry claims, all without leaving the terminal flow you already use.

Searches for how to add an MCP server to Codex usually hide a second question: which of the two routes is the real one, the command or the config file. They are the same route seen from two sides. The codex mcp add command writes an entry into the Codex config file, ~/.codex/config.toml, and editing that file by hand produces the identical result. This page gives both, mirrors the config format Codex actually reads, and then insists on the step most guides skip: a first call whose receipt you check at a public verifier, because a server listed is not the same thing as a server proven.

The one command route

Run this in your terminal:

codex mcp add zambo --url https://zambo.dev/mcp

That is the whole install. There is nothing to download and no local server process to manage, because Zambo is hosted and remote: Codex connects out to https://zambo.dev/mcp when a session starts. No API key is needed, and no environment variable has to be set or kept secret in your shell history. The command adds the entry under the name zambo, which is the name you will see in listings and the name sessions will show when a Zambo tool is picked. If you run the command twice, check the listing afterwards rather than assuming a duplicate: one clean entry is what you want.

The config file route

Open ~/.codex/config.toml and add this block, keeping any servers and settings you already have:

[mcp_servers.zambo]
url = "https://zambo.dev/mcp"

Note the format differences from the JSON configs most editors use, because they are where hand edits go wrong. Codex config is TOML, not JSON: the server lives under a table header, [mcp_servers.zambo], with an underscore in mcp_servers, and the address is a quoted string on its own line. There is no command or args entry, because this is a remote server reached by URL, not a local program Codex launches. A block copied from a Cursor, Cline, or VS Code guide will not work pasted in as JSON; translate it into this two line shape instead. If the file already has an mcp_servers section for other servers, add zambo as its own table under the same pattern rather than nesting it inside another server block.

Step by step, verified in order

First, add the server by either route above. Second, verify the entry exists before starting a session: run codex mcp list and look for zambo with the address https://zambo.dev/mcp. If zambo is missing, you edited a different config file than Codex reads, or the TOML has a syntax error above the new block; fix the file until the listing shows it. Third, start a fresh Codex session in the project you want to work in, because sessions read the config when they start and an already running session will not pick up a server added after it launched. Fourth, ask for the first call below, something small and checkable. Fifth, open the receipt link from the result and run the free check at the verifier. Only after that loop passes should Zambo become part of real runs, reviews, and deliveries.

Scope is worth one decision up front. The config at ~/.codex/config.toml is your user config, so the entry applies to Codex sessions you run on that machine, across projects. That is normally what you want for a general tool server like Zambo: connect once, use everywhere, keep one account behind it. Project level overrides exist in Codex setups for teams that pin tooling per repo, but for a first connection the user config is the simple, findable, removable choice, and removing the server later is just as small: delete the block, or remove it through the same mcp command family you added it with.

Verify the connection properly

The listing proves Codex can read the config. Only a round trip proves the connection. In a fresh session, ask Codex to use Zambo for a small job with an answer you can judge, a current price lookup or an audit of a public page. The result returns with a receipt link. Open it, copy the receipt ID, and paste it into zambo.dev/verify: a match confirms the saved result was not changed after the fact, and it confirms the practical chain too, terminal, config, remote endpoint, and public record all agreeing. That loop, call, receipt, verify, is the whole point of running verifiable steps through Zambo instead of letting them rest on a session summary.

The default connection loads 35 tools, out of 153 in total, which is the right size for coding sessions where the model is also holding your repo. If a run genuinely needs the wider catalogue, the same entry with the address https://zambo.dev/mcp?full=true exposes all 153 tools. Use full for audits, sweeps, and exploration, then switch back: a permanent full surface spends model attention on tools most sessions never call. Either way the account, the memory, and the receipts are the same, because they live server-side, not in the config entry you edited.

Good first jobs for Codex with Zambo

Route the steps that carry claims. During a fix, ask Codex to run the external check, the live audit, the source verification, the price or status lookup, through Zambo, so the claim in its summary points at a receipt instead of at its own narration. Before a refactor, ask it to save the decisions and constraints to memory, so the session next week, or a different AI entirely, recalls them instead of re-deriving them. At delivery, ask it to assemble the routed steps into a handover, one link with the goal, steps in order, outputs, and receipts, that a client or reviewer opens with no account and accepts or flags. Code edits and local commands stay in the repo where they belong; the evidence about the run accumulates beside them, which is exactly the split an honest record needs.

What the connection unlocks

One connection changes four things at once, and it helps to keep them separate, because people usually come for the first and stay for the other three. Tools: your AI stops being limited to conversation and can run real jobs, lookups, checks, audits, file and data work, lead finding, and more, through the 153 tools on the Zambo endpoint, with 35 loaded on the default surface so the session stays focused. Memory: facts you explicitly save with memory_remember are held on your Zambo account and come back with memory_recall, in this client and in any other AI connected to the same account, so a decision saved today is present next week without you retyping the backstory. Continuity: work state saved in one AI can be opened in another, so hitting a limit or changing tools mid job means continuing, not restarting. Receipts: each saved tool result is filed with a verifiable receipt in the AER-1 format, draft-zambo-aer1-24, and anyone can check it free at zambo.dev/verify with no signup.

The flagship on top of those four is handover: when a job is done, the goal, the steps in order, the outputs, and the receipts travel in one link that a client or teammate opens with no account and accepts or flags. Try the shape before you rely on it: run a job end to end at the live demo, open the record it produces, then follow a recorded day at zambo.dev/today. The endpoint itself, https://zambo.dev/mcp, is the same one URL for every client on this page and every sibling guide, which is the point: connect once per client, keep one account, and let the work, the memory, and the proof accumulate in one place instead of scattering across apps.

What it costs

You can start on the free tier, and checking a receipt is always free. For $0.99, a Day Pass covers 24 hours of full use, framed for this page as one full day of connected work where every job you run leaves a record you can show someone. Ongoing use is the Zambo Pass at $29 a month or $290 a year, and $19 a month for $ZAMBO holders; see pricing for the current tiers. Humans pay by PayPal or card through PayPal; agents pay USDC on Base through x402. Nothing about the connection itself costs anything: the config entry, the command, and the first verification call are all free to try.

Troubleshooting

• zambo is missing from codex mcp list. You edited a different file than Codex reads, or the TOML is broken. Open ~/.codex/config.toml, find the [mcp_servers.zambo] block, and validate the file structure from the top.
• The config worked in another editor but not here. Codex config is TOML with mcp_servers tables. JSON blocks with mcpServers keys belong to other clients and must be translated, not pasted.
• The server is listed but the session cannot see the tools. Start a fresh session after adding the entry; running sessions keep the config they launched with.
• The address looks right but calls fail. The value must be exactly https://zambo.dev/mcp, quoted, with https and no extra path. A stray trailing slash or an added subpath breaks it.
• Calls fail partway through a long run. If earlier calls in the run returned receipts, the connection is proven and a usage limit is the likelier cause; a Day Pass or Zambo Pass raises it.

Honest limits

Frequently asked questions

Related

• Add an MCP server to VS Code, the mcp.json version
• Add an MCP server to Windsurf, the serverUrl version
• Give your AI tools: what connecting an MCP server actually gives it
• Add Zambo MCP to Gemini CLI, step by step
• Codex receipts: a checkable record for every run
• Add Zambo MCP to Cline, step by step