Codex — Part 9 — Connecting External Tools with MCP
MCP lets Codex read and act on systems outside your local filesystem, shared across the desktop app, CLI, and IDE extension through the same config.toml.
A connector between Codex and one external system: a tracker, a database, an API.
Registers a stdio server directly from the command line, writing correct TOML for you.
Shows every configured server and its status.
Introduction
Every post so far in this series has worked with what is already on your machine. MCP is the mechanism that extends Codex past the local filesystem, to a ticket tracker, a browser, a design tool, or an internal API. This is the last post in this series before the daily-ops use cases begin, the same closing point the Claude Code series reached in its own Part 9.
What Is MCP?
Model Context Protocol connects models to tools and context. It is the same open standard covered in the Claude Code series, so a server built for one tool generally works for the other. In Codex specifically, the same MCP configuration is shared seamlessly across the desktop app, the CLI, and the IDE extension, since they all read from the same config.toml.
Adding a Server
A local, process-based server is registered directly from the command line.
# Add a local stdio server
codex mcp add context7 -- npx -y @upstash/context7-mcp
# Add a stdio server with environment variables
codex mcp add my-server --env API_KEY=your-key -- npx -y some-mcp-server-- is passed straight through as the server’s own command and arguments. codex mcp add writes syntactically correct TOML for you, which is worth using for the initial add even if you plan to hand-edit the entry afterward.
Remote HTTP servers are configured directly in config.toml instead, since they need a url rather than a local command.
# %USERPROFILE%\.codex\config.toml
[mcp_servers.notion]
url = "https://mcp.notion.com/mcp"
auth = "oauth"Configuration Structure
| Field | Applies To | Purpose |
|---|---|---|
command, args, env, cwd | Stdio servers | The local process to run and its environment |
url, auth, bearer_token_env_var | HTTP servers | The remote endpoint and how to authenticate to it |
enabled, required | Both | Whether the server loads at all, and whether Codex should fail if it cannot connect |
enabled_tools, disabled_tools | Both | Narrows which tools from the server are actually exposed |
startup_timeout_sec, tool_timeout_sec | Both | How long Codex waits before giving up on connection or a tool call |
Transport is inferred from which fields are present, a command means stdio, a url means HTTP. There is no separate transport key to set by hand.
Checking Status
# List every configured server
codex mcp list
# Authenticate an OAuth-based remote server
codex mcp login notion
# Inside a session: list configured MCP tools
/mcpFinal Thoughts
That closes the foundations part of this series, and it lands in almost exactly the same place the Claude Code series did: installed, a real project running, AGENTS.md carrying standing rules, a Skill for repeatable procedures, subagents for noisy parallel work, an approval and sandbox model actually understood rather than guessed at, a troubleshooting reference, and now MCP for reaching outside the local machine.
The two tools differ in plenty of specifics covered across this series, AGENTS.md’s byte limit versus CLAUDE.md’s line guideline, parallel TOML-defined subagents versus a single delegated worker, sandbox and approval as two independent layers versus a tiered allow/ask/deny system. The underlying shape, and the reason either is worth an IT engineer’s time, is identical.
codex mcp add for the initial setup of a local server, and verify you trust a server before connecting it, since the prompt injection risk applies here the same as anywhere else.
With the foundations in place, the series moves on to real daily-ops use cases: writing and debugging scripts, triaging logs and event IDs, and building the first hands-on project.