What is MCP in Codex? The answer for Codex CLI teams

MCP is the connector layer that lets an agent read context and act across the systems your team already uses, the same way in Codex and in Codex CLI, OpenAI's coding agent. So if you searched the phrase while planning a rollout, the honest answer is that the protocol is the easy part. The hard part is deciding what a connected agent may touch inside a shared repo, and that decision is yours to write down.

Here is the pattern I keep seeing. Someone installs a few MCP servers, the demos get faster, and a week later the reviews get slower. Diffs read clean but quietly touched a system nobody on the review could see. That gap is what this piece is about.

What MCP actually is, in one minute

MCP, the Model Context Protocol, is a standard way to connect an agent to external systems: your docs, your issue tracker, a read-only view of your logs. The MCP specification defines the wiring so a server you write or install can plug into Codex, Codex CLI, or anything else that speaks the protocol.

What it does not define is your boundaries. The spec tells the agent how to call a system. It says nothing about which systems this repo trusts, or what proof a change should leave behind. That part stays your job, and skipping it is where rollouts go sideways.

You can watch the broader direction in the AIE Singapore Day 1 session: vendors are converging on connected agents that read context, call approved systems, and act across longer delivery paths. The wiring is becoming standard. The governance is not.

Write a repo MCP contract before the first server ships

The fix is small and boring on purpose: one short artifact per repository, kept next to the AGENTS.md file that Codex CLI already reads. It says which connectors are welcome here and what an agent owes you after using them.

## MCP contract for this repository

- Approved servers: docs, issue tracker, read-only observability
- Forbidden servers: production database writes, billing systems, personal drives
- Required proof after use: command summary, files changed, validation command, owner
- Human review required when: auth, payments, infra, secrets, or migrations are touched
- Rollback note required before merge: yes

This closes the gap between "we support MCP" and "we can review MCP-assisted work." Keep it narrow at first. Widen the approved list only while reviews stay predictable, repo by repo, instead of flipping everything on at once.

Make every connected change leave a receipt

Connectors feel like magic until something breaks and nobody can reproduce the run. The cure is a short evidence trail attached to each MCP-assisted change. Five lines is enough:

• Why the connector was needed
• Which connector was used
• What the agent changed after using it
• Which validation command passed
• Who approved the riskier step

Once engineers write these, connectors stop reading like helpful magic and start reading like governed dependencies, the kind you already review with care. Before any broad rollout, run one rehearsal where Codex uses only read-only servers and the reviewer signs off from the evidence trail alone, with no chat history allowed. If a team cannot explain how Codex used MCP in a change, the workflow is not ready to scale.

Four questions decide readiness, and they need shared answers: which servers are approved for this repo, which actions are allowed and forbidden on each, what proof the agent must leave, and who owns the rollback when a connected workflow lands a bad change. Those same questions anchor the Plan step in our methodology. The rest of the drill set lives under CLI workflows.

Common questions

• What is MCP in Codex?

  MCP is the connector layer that turns agent work into system-aware work, the same in Codex as in Codex CLI. The useful way to think about it is as a workflow question, not protocol trivia. Decide connector scope, repo rules, verification steps, and ownership before agents touch shared code, and the protocol detail mostly takes care of itself.

• Which questions need answers before a broad MCP rollout?

  Four, and they need shared answers across the team. Which MCP servers are approved for this repository. What actions are allowed and forbidden on each server. What proof the agent must leave after using a connector. And who owns the rollback if a connected workflow causes a bad change. Answer these and the rollout stays reviewable.

• What belongs in a repository MCP contract?

  Five lines kept next to AGENTS.md: approved servers, forbidden servers, required proof after use, the cases where human review is mandatory, and whether a rollback note is required before merge. The artifact closes the gap between supporting MCP and actually being able to review MCP-assisted work without guessing what an agent touched.

• What evidence should an MCP-assisted change leave behind?

  A short trail with five parts: why the connector was needed, which connector was used, what the agent changed after using it, which validation command passed, and who approved the riskier step. That trail turns connectors from helpers you trust on faith into governed dependencies inside your delivery process.

Next move

If your connector list is already longer than your contract, write the five-line contract first, then talk to us and we will pressure-test it against one of your live repositories.