The uncomfortable truth about MCP servers in Codex is simple.
They are useful.
They are also not free.
I do not mean only pricing.
I mean context.
Every tool you connect has to be described somewhere.
Every external system you expose changes what Codex can consider.
Every server you leave enabled becomes one more thing the agent has to carry into the session.
That is wonderful when the task truly needs it.
It is wasteful when the task does not.
OpenAI says this very directly in the Codex pricing documentation.
To make usage limits last longer, users should control prompt size, reduce the size of AGENTS.md, limit the number of MCP servers, and switch to a smaller model for routine tasks.
That sentence is more important than it looks.
It means MCP is not just a connector decision.
It is a context-budget decision.
This post turns that into a practical checklist.
The question is not “Should I use MCP with Codex?”
The better question is this:
When should an MCP server be enabled by default, enabled only for one task, or disabled entirely?
The short answer
Disable an MCP server when the current Codex task can be completed from the repository, the terminal, and a small set of local files.
Keep an MCP server enabled when the task truly needs live external context, repeatable tool access, or a workflow that would otherwise require copy-pasting changing data.
Use task-scoped MCP when the server is useful but heavy, risky, or only relevant for a narrow phase.
That is the whole operating model.
| Situation | MCP setting | Why |
|---|---|---|
| Fixing a local bug with clear files | Disable extra MCP servers | Local context is enough |
| Checking current docs or API behavior | Enable a docs MCP | The source changes |
| Inspecting a UI in a browser | Enable Playwright or browser MCP for that task | The tool is part of verification |
| Reading Sentry or production logs | Enable Sentry only when needed | High-value, high-noise context |
| Writing a tiny refactor | Disable nonessential MCP | Tool descriptions are overhead |
| Repeated design-to-code workflow | Keep Figma MCP configured but scoped | It removes a real manual loop |
The point is not to be minimal for sport.
The point is to keep Codex sharp.
Sharp sessions are not always the biggest sessions.
Often they are the cleanest sessions.
Why MCP changes the shape of a Codex session
OpenAI describes Model Context Protocol as a way to connect Codex to tools and context.
That includes third-party documentation, browser tools, Figma, Sentry, GitHub, and other developer systems.
This is exactly why MCP is powerful.
It lets Codex act on live context instead of stale pasted snippets.
It can inspect a browser.
It can search updated docs.
It can read product telemetry.
It can interact with systems your repo alone cannot represent.
But that same power changes the session.
A Codex session with no MCP is mostly about the prompt, the repository, local commands, and instructions.
A Codex session with many MCP servers is also about all the tools Codex might choose.
The model needs to understand what exists.
It needs to decide whether a tool is relevant.
It needs to avoid using the wrong tool.
It needs to include more tool metadata in the operating context.
That is why “just leave everything on” can feel convenient at first and expensive later.
You are paying with attention before you pay with anything else.
The four context levers OpenAI calls out
OpenAI’s Codex usage guidance gives four levers.
They are worth treating as one system.
| Lever | What it controls | Practical move |
|---|---|---|
| Prompt size | The text you send each turn | Remove background that does not affect the task |
AGENTS.md size |
Durable instructions injected into sessions | Keep root guidance short and move local rules closer to work |
| MCP server count | Tool and external context surface area | Disable servers that are not needed for the current task |
| Model choice | Local-message usage pressure | Use smaller models for routine tasks when appropriate |
Many teams only look at the first lever.
They shorten prompts.
That helps.
But if the session still loads a large AGENTS.md and several irrelevant MCP servers, the prompt is not the whole story.
Context discipline is not one switch.
It is a budget.
You spend it on the things that improve the answer.
You stop spending it on things that only make the setup feel impressive.
That last part is rude, but useful.
Decision checklist: disable, scope, or keep
Use this checklist before starting a Codex task.
| Question | If yes | If no |
|---|---|---|
| Does the task require live data outside the repo? | Enable the specific MCP server | Keep it disabled |
| Would copy-pasting the same data be worse or less repeatable? | MCP may be worth it | Use prompt context instead |
| Is the MCP output likely to be large or noisy? | Scope it to the task | Avoid default enablement |
| Is the server needed in almost every session for this repo? | Consider project config | Keep it manual |
| Is the task a small local edit? | Disable extras | Reconsider only if blocked |
| Does the MCP carry sensitive or production context? | Use tighter scope and explicit intent | Leave disabled by default |
The phrase “by default” matters.
You are not deleting the tool from your life.
You are deciding whether it should be part of every Codex session.
Default context should earn its rent.
If a server is useful twice a month, it probably should not load into every task.
If a server is useful in every UI verification flow, it can be configured but still enabled only when that workflow starts.
A simple three-tier MCP policy
Here is the policy I like.
It is boring.
That is why it works.
| Tier | Meaning | Examples |
|---|---|---|
| Always-on | Needed in most sessions for this repo | Core internal docs, a narrow code-search server |
| Task-scoped | Useful for a specific phase | Browser, Figma, Sentry, API docs |
| Off by default | Rare, noisy, risky, or experimental | Broad production tools, one-off research servers |
Always-on should be tiny.
If everything is always-on, nothing is intentional.
Task-scoped is where most MCP servers belong.
They are excellent when the job needs them.
They are overhead when it does not.
Off by default is not a punishment.
It is a parking lot.
The server can come back when the task asks for it.
Examples
Example 1: local unit test failure
You ask Codex to fix a failing unit test.
The failure points to one module.
The relevant source files are in the repo.
The test command is known.
You do not need Figma.
You do not need Sentry.
You do not need browser automation.
You probably do not need a docs MCP either unless the failure involves a third-party API.
Disable extra MCP servers.
Give Codex the failing command, the expected behavior, and the relevant files.
That session will usually be sharper.
Example 2: documentation-dependent migration
You are upgrading a framework and the official docs changed recently.
Now an MCP server for current documentation makes sense.
The repo alone may be stale.
A random blog post may be stale.
The MCP server can reduce copy-paste and keep the workflow repeatable.
Keep the docs MCP enabled for that migration task.
Then disable it when the migration is over.
Example 3: UI bug verification
You ask Codex to fix a visual bug.
The only way to know whether it is fixed is to open the local app, inspect the DOM, and capture a screenshot.
A browser or Playwright MCP may be worth the context cost.
Here the tool is not decoration.
It is the verification method.
Without it, Codex may make a plausible edit and stop too early.
Example 4: production incident triage
You want Codex to inspect Sentry logs.
That can be high value.
It can also be noisy and sensitive.
Do not leave that server as casual background context for every refactor.
Enable it only for incident work.
Tell Codex exactly what to query.
Ask for a summary, not a dump.
Then return to a smaller setup.
How AGENTS.md fits into the same budget
MCP is only one side of the problem.
AGENTS.md can create the same issue in a quieter way.
OpenAI’s AGENTS.md guide says Codex reads instruction files before doing work.
It builds an instruction chain from global guidance, project guidance, and more specific files closer to the working directory.
Files closer to the current directory override earlier guidance.
Codex also has a combined size limit for project instructions, with 32 KiB as the documented default.
That should change how you write instructions.
Do not put every possible rule in the root file.
Use the root for durable, common expectations.
Move specialized rules into subdirectories.
If only the payments service needs a rule, put it near the payments service.
If only blog publishing needs a rule, put it near the blog workflow.
The context-budget principle is the same as MCP.
Default guidance should be small.
Specific guidance should appear when the work enters that area.
A practical startup ritual
Before a Codex session, ask these five questions.
| Step | Question |
|---|---|
| 1 | What is the goal of this task? |
| 2 | Which files or folders matter? |
| 3 | Which durable instructions are actually relevant? |
| 4 | Which MCP servers are necessary for this goal? |
| 5 | What proves the task is complete? |
If the answer to step 4 is “not sure,” start with fewer MCP servers.
You can enable one later.
Starting small is not the same as staying small.
It just prevents the session from beginning bloated.
This is especially useful for long-running work.
Once a session gets crowded, cleanup is harder.
You can compact.
You can summarize.
You can fork.
But the cleanest context is the context you never polluted.
Tiny bit dramatic, yes.
Still true.
What to put in the prompt instead
Disabling MCP does not mean starving Codex.
It means giving it the right context manually when that is cheaper.
A good Codex prompt can be short and complete.
Goal:
Fix the failing parser test for quoted CSV fields.
Context:
- Relevant files: src/parser.ts, tests/parser.test.ts
- The failure started after commit abc123.
- Do not change public API behavior.
Constraints:
- Keep the patch minimal.
- Add a regression test.
- Follow existing test style.
Done when:
- npm test -- parser passes.
- Review the diff for regressions.
That prompt does not need a browser MCP.
It does not need Figma.
It does not need Sentry.
It needs clarity.
Clarity is cheaper than tooling.
Tooling is better when clarity requires external access.
Signals that an MCP server is hurting more than helping
Watch for these signs.
| Signal | What it may mean |
|---|---|
| Codex keeps considering irrelevant tools | Too many servers are enabled |
| The session feels slow before useful work starts | Tool/context surface is too large |
| The answer references external systems you did not ask for | Default context is too broad |
| Routine edits consume too much usage | Prompt, AGENTS.md, and MCP overhead need trimming |
| The agent fetches huge outputs and summarizes poorly | Scope the query or use a narrower tool |
| You cannot explain why a server is enabled | Disable it until a task needs it |
The last one is my favorite.
If you cannot explain why a server is enabled, it is probably decor.
Decor is fine in a living room.
Less fine in an agent context window.
A weekly context-budget review
Once a week, review your Codex setup.
This does not need to be a ceremony.
Five minutes is enough.
| Review item | Action |
|---|---|
| MCP servers | Disable servers not used this week |
AGENTS.md |
Remove vague rules and repeated advice |
| Project overrides | Move specialized guidance closer to the relevant folder |
| Skills | Turn repeated long prompts into a focused skill |
| Automations | Automate only workflows that are already reliable manually |
This matches OpenAI’s broader best-practices direction.
Codex works better when reusable guidance lives in the right place.
AGENTS.md is for durable repo guidance.
MCP is for external tools and changing context.
Skills are for repeatable methods.
Automations are for stable schedules.
When those layers blur, the session gets heavy.
When they stay separate, Codex feels calmer.
Yes, I just called a coding agent calmer.
You know exactly what I mean.
Related posts
I wrote a Korean companion post on the same operating problem: Codex์์ MCP ์๋ฒ๋ฅผ ์ค์ด๋ฉด ์ง์ง ์ฌ์ฉ๋์ด ์ค๋ ๊ฐ๊น 2026.
For a broader tool-splitting view, see Gemini CLI next to Codex and Claude Code.
For a Claude Code comparison point, see Claude Code context discipline in 2026.
FAQ
Should Codex users disable all MCP servers by default?
No.
Disable the servers that are irrelevant to the current task.
Keep the ones that provide live context, repeatable verification, or tool access that the task truly needs.
Does disabling MCP make Codex less capable?
Sometimes.
If the task needs a browser, current docs, Figma, Sentry, or GitHub context, disabling the relevant MCP can make Codex worse.
The goal is not fewer tools.
The goal is the right tools for the current job.
Is AGENTS.md part of the same context problem?
Yes.
OpenAI’s AGENTS.md guide explains that Codex builds an instruction chain from global and project files.
That guidance is useful, but oversized or vague instructions can become background noise.
Keep durable rules concise and put specialized rules close to the folders that need them.
When should an MCP server be always-on?
Only when it is useful in most sessions for that repository.
Examples might include a narrow internal docs server or a small code-search integration.
Broad, noisy, sensitive, or rarely used tools should usually be task-scoped.
What is the easiest first improvement?
List your enabled MCP servers and ask whether the next task actually needs each one.
Disable the ones that do not affect the goal.
Then shorten the prompt and check whether AGENTS.md is carrying stale advice.
Should routine tasks use a smaller model?
OpenAI’s Codex pricing guidance says switching to GPT-5.4 or GPT-5.4-mini can extend local-message usage limits depending on the model you switch from.
For routine edits, formatting, or small checks, that can be part of the budget.
For complex debugging, use the model and reasoning level the task deserves.
๊ณต์ ์ถ์ฒ/์ฐธ๊ณ ์๋ฃ
- OpenAI Developers, Codex pricing – usage limit tips, guidance on prompt size,
AGENTS.md, MCP server count, and smaller models. - OpenAI Developers, Model Context Protocol, Codex MCP support, configuration, STDIO and HTTP servers, OAuth, enabled/disabled tools, and example servers.
- OpenAI Developers, Custom instructions with AGENTS.md, instruction discovery, precedence, nested guidance, and project instruction size limits.
- OpenAI Developers, Codex best practices, recommended patterns for prompts,
AGENTS.md, MCP, skills, automations, review, and session controls.
Closing note
MCP servers are one of the best parts of Codex.
They make the agent less isolated.
They connect it to the real systems where work happens.
But the same connection can bloat a session when it becomes default background noise.
So the rule is simple.
Use MCP when it removes a real manual loop.
Disable it when it only makes the session look powerful.
The best Codex setup is not the one with the longest tool list.
It is the one where every enabled tool has a job.
That is context budgeting.
Not glamorous.
Very profitable.