Setting up Codex CLI MCP without regret

What you are actually adding

Codex CLI MCP support means the agent can call tools provided by an external process: a database client, a docs index, an issue tracker, a browser. The server advertises its tools, Codex adds them to what the model can call, and from then on the agent can fetch instead of asking you to paste.

The part people skip is the bill. Every enabled server's tool names, descriptions, and parameter schemas sit in the prompt on every turn. Two lean servers cost almost nothing. Five fat ones eat a meaningful slice of your window before you have typed a word, and the symptom is not an error. It is the agent quietly getting worse at the coding task, choosing the wrong tool, or losing an instruction from earlier in the session.

Servers that are worth it in Codex CLI MCP setups

Judge each one by a single question: does it answer something the agent currently guesses at?

• A database server on a read-only replica. Guessing schema from an old migration file is one of the most common sources of confidently wrong code. This kills it.
• Documentation for libraries that move faster than training data. Useful in proportion to how new your stack is.
• An issue tracker, but only if your tickets carry real acceptance criteria. If they say "fix checkout", you have added tokens and nothing else.
• A browser or preview server for anything with a rendered UI, so the agent can look rather than assert.

Skip wrappers around things the shell already does well. A git MCP server is usually a downgrade from letting the agent run git log --oneline -20 or git diff main... directly, because the shell version composes and the wrapper does not.

Configuration and credentials

Codex reads its configuration from a config file in the Codex home directory, and MCP servers are declared there as a command plus arguments, the same shape every MCP client uses. Keep the declaration in version control if it is project-specific and safe to share. Keep the secrets out.

Reference environment variables rather than pasting tokens, and write down in your repo README which variables a new joiner needs to export. We have opened team repos where a live API token had been sitting in a committed agent config for months. It happens because that file reads like editor settings, and editor settings do not get reviewed.

The failure modes that look like a bad model

A server that fails to start does not announce itself loudly in the middle of your session. The tools simply are not there, and the agent falls back to guessing. If the answers go vague after a machine restart or a dependency bump, check that the process is running before you blame the model or switch tools.

Permissions are the sharper edge. An MCP server runs with whatever access you gave it. Pointing one at production with write credentials is an incident waiting for a badly phrased prompt on a Friday. Use a read-only replica or a scoped account, and assume the agent will eventually try the destructive thing.

Treat what comes back as untrusted input. Text returned by an external server can contain instructions aimed at the agent, and a well-behaved harness will not filter that for you. Same reasoning as not evaluating a webhook body.

What to do next

Add exactly one server: whichever fixes the thing your agent gets wrong most often. For most backend teams that is the database schema. Run it for a week, and note every time the connection actually changed an answer. If you cannot name three occasions, remove it and try a different one. Adding five at once teaches you nothing about which is carrying its weight.

If you want help putting this into practice, talk to us.