A ranked list of the best MCP servers for Codex, from OpenAI Docs MCP and Context7 to GitHub, Playwright, Chrome DevTools, and Figma. It includes ready-to-paste config.toml snippets, approval settings that keep write access in check, and a way to add image generation to the stack.
Codex writes code well on its own. What it cannot do alone is read the docs for the library version you installed this morning, open a pull request, click through your checkout page, or look at the error that fired in production an hour ago. MCP servers close that gap. Each one hands Codex a set of tools over the Model Context Protocol, and the right handful turns a capable assistant into one that can carry a ticket from description to merged change.
This ranking is built around what developers reach for in real projects: documentation, source control, browsers, design files, and error tracking. It starts from OpenAI's own Codex documentation, which names a short list of recommended servers, then adds the extras that earn a place in a working setup. Along the way you get config.toml snippets you can paste, a way to keep permissions tight, and a look at adding image generation to the same stack.
💡 Quick answer: install OpenAI Docs MCP, Context7, GitHub, and Playwright first. Add Chrome DevTools, Figma, and Sentry only when a project needs them.
Codex reads its settings from ~/.codex/config.toml. That single file is shared by the CLI, the IDE extension, and the desktop app, so a server you register once shows up everywhere. Each server gets its own [mcp_servers.<name>] table, and Codex connects to the enabled ones at startup.
An MCP server is a small program, or a hosted endpoint, that advertises a list of tools. Codex connects, reads that list, and can call those tools in the middle of a task. A GitHub server exposes pull request actions. A docs server exposes search. Codex decides when to call a tool, and your approval settings decide whether it has to ask you first.
The practical effect is fewer guesses. Instead of writing against a remembered version of an API, the assistant looks it up. Instead of telling you a fix "should work", it opens a browser and checks.
The transport depends on which fields you write. A command means Codex launches a local stdio process. A url means it talks to a remote streamable HTTP server.
| Stdio server | Streamable HTTP server | |
|---|---|---|
| Selected by | command | url |
| Runs | A local process Codex launches | A remote service |
| Typical setup | npx package plus args | OAuth or a bearer token |
| Credentials | env or env_vars | auth (OAuth by default) or bearer_token_env_var |
| Good for | Docs lookups, browsers, local files | Hosted services like issue trackers |
💡 For remote servers that use OAuth, run
codex mcp loginonce. Inside the terminal UI,/mcpshows which servers are active right now.
The order below follows two rules. Servers that only read rank above servers that write. Servers that rescue Codex from stale information rank above servers that merely save you a click. Five of the six come straight from the list OpenAI recommends in its Codex documentation.
| Rank | Server | Best for | Write risk |
|---|---|---|---|
| 1 | OpenAI Docs MCP | Current OpenAI API and Codex answers | Very low |
| 2 | Context7 | Version-specific library docs | Very low |
| 3 | GitHub | Pull requests, issues, CI runs | Medium |
| 4 | Playwright | Driving a real browser | Medium |
| 5 | Chrome DevTools | Console, network, performance | Low |
| 6 | Figma | Building from real design files | Low |
A ranking only tells you what is good in general. What you install first depends on the project in front of you:
| Project type | Install first | Add later |
|---|---|---|
| Solo front-end app | Context7, Playwright, Chrome DevTools | Figma |
| Backend API service | Context7, GitHub, Sentry | A read-only database server |
| Team repository with CI | GitHub, Linear, Context7 | Playwright, Sentry |
If the app itself calls OpenAI APIs, add OpenAI Docs MCP to any row. It costs almost nothing and stops a whole class of outdated-parameter bugs.
Codex knows what it was trained on, and that can lag behind a renamed parameter or a new endpoint. The OpenAI Docs server lets it check the current documentation instead of guessing. It only reads, so there is almost nothing to go wrong.
If your app calls OpenAI APIs, or you ask Codex questions about its own configuration, this is the highest-return install on the list. It earns first place by being both useful and nearly risk free.
Context7 fetches current, version-specific documentation for libraries and frameworks and drops it into context on demand. It attacks the most common agent failure: confidently writing against an API that changed two major versions ago.
One command registers it:
codex mcp add context7 -- npx -y @upstash/context7-mcp
Or write the same thing by hand, with a longer startup window for the first npx download:
[mcp_servers.context7]
command = "npx"
args = ["-y", "@upstash/context7-mcp"]
startup_timeout_sec = 20
💡 Add one line to your
AGENTS.md, such as "use Context7 for library documentation", so Codex reaches for it without being asked every time.
For most teams, the official GitHub server is the highest-impact connection after docs. Codex can read and comment on pull requests, search code across repositories, triage issues, and inspect failing CI runs. That turns "why is this build red?" from a ten-minute tab hunt into one prompt.
It is also the first server on this list that can change things, so configure it with care:
[mcp_servers.github]
url = "https://api.githubcopilot.com/mcp/"
bearer_token_env_var = "GITHUB_MCP_TOKEN"
default_tools_approval_mode = "prompt"
Confirm the endpoint against GitHub's own README before you copy it, because hosted URLs can move. Keep the token in an environment variable, scope it to the repositories you actually work in, and start with read access.
Microsoft's Playwright server gives Codex a real browser to drive. It opens pages, fills forms, clicks controls, reads the page through its accessibility tree, and keeps browser state across a debugging session. The difference shows in the wording of the answer: "I made the change" becomes "I made the change and confirmed it renders."
[mcp_servers.playwright]
command = "npx"
args = ["@playwright/mcp@latest"]
Use it for checkout flows, form validation, and anything where the bug only appears after three clicks. Because it can submit forms and click buttons, point it at a staging site, not production.
OpenAI's documentation lists Chrome DevTools and Playwright as alternatives, but they solve different problems. Playwright automates a flow. DevTools inspects a page. When the question is "why is this slow?" or "what is that console error?", the DevTools server lets Codex look at the network panel, the console, and performance data instead of reasoning from source code alone.
Many projects end up running both. If you can only pick one, choose Playwright for test-style work and DevTools for performance and rendering bugs.
Without a design server, Codex builds from a screenshot or your description, and spacing drifts. With the Figma server, it can pull structured information from the file itself: layout, spacing, colors, and component structure. The result is a first draft much closer to what the designer shipped.
It ranks last on the short list only because it matters to fewer projects. On a front-end team with a living design file, it can move up to second place.
Once the core six are stable, a few more connections pay for themselves on specific kinds of work. Check each vendor's current documentation for the endpoint and permission scopes, since these change faster than a blog post can.
Sentry publishes an MCP server that can hand Codex stack traces and recent errors, so a bug report starts with the real failure rather than a paraphrase. Linear publishes one too, which lets Codex read the ticket text and acceptance criteria before it writes anything. Together they close the loop: the error says what broke, the ticket says what "fixed" means.
Database servers deserve a warning. A server wired to a production database turns a typo into an incident. Point it at a read-only replica or a local copy, and keep every write tool disabled.
You can add servers two ways, and they produce the same result.
The command line is the fastest route for a single server:
# local stdio server
codex mcp add playwright -- npx @playwright/mcp@latest
# remote streamable HTTP server
codex mcp add github --url https://api.githubcopilot.com/mcp/
# see what is configured, and log in to OAuth servers
codex mcp list
codex mcp login github
codex mcp add writes to the same config.toml, and you can pass --env NAME=VALUE for local servers that need environment variables. Run codex mcp --help for the full command list.
After every install, run the same three checks before you trust a server:
/mcp and confirm the server shows as active.If step one fails, the cause is usually a startup timeout, a missing environment variable, or a package that needs its first download. Fix that before you add the next server, so you always know which change broke what.
For a stack you will reuse, edit the file. It also lets you set the options the CLI does not prompt for. These are the ones that matter most:
| Field | Default | What it does |
|---|---|---|
startup_timeout_sec | 10 | How long Codex waits for a server to start |
tool_timeout_sec | 60 | How long a single tool call may run |
enabled | on | Turns a server off without deleting it |
required | off | Fails startup if the server cannot initialize |
enabled_tools | all | Allow list of tools Codex may use |
disabled_tools | none | Deny list of tools Codex may not use |
default_tools_approval_mode | varies | auto, prompt, writes, or approve |
Every connected server widens what the assistant can touch. A few habits keep that manageable.
A server may expose dozens of tools, and you rarely need all of them. Use enabled_tools to list exactly what Codex may call, or disabled_tools to remove the dangerous few. A shorter tool list also means less text for the model to read and fewer wrong choices.
Mark required = true only for servers a task cannot work without. If a nice-to-have server fails to start, you want Codex to carry on, not stop.
The default_tools_approval_mode field takes four values in the documentation: auto, prompt, writes, and approve. Read the reference page for the exact behavior of each before you rely on one. As a rule of thumb, use a prompting mode for any server that can create, edit, or delete things, and leave read-only documentation servers on a looser setting.
💡 A sensible starting policy: docs servers on a relaxed mode, GitHub and Playwright set to prompt, database servers read-only with writes disabled.
Codex can write a landing page, but it cannot paint the hero image. PicassoIA offers an MCP connection and a developer API so an assistant can generate visuals as part of the same task. Connection details live on the MCP connections page of your PicassoIA account, which requires a login.
Four models are available through the API and the MCP connection:
The server URL is not published on PicassoIA's public pages, so copy it from your account. If it gives you a remote URL, register it with the --url flag shown above, then confirm it appears in /mcp before you build a workflow around it.
The API is asynchronous: you create a prediction, poll for its status, then fetch the result. Plan around these limits:
Here is a prompt pattern worth trying once the connection works: ask Codex to build the hero section of a page, then to call the image tool with a 16:9 photographic prompt that matches the page's topic, and finally to reference the returned image URL in the markup. One task, no tab switching, and the image brief comes from the same context as the copy.
If a generation call times out inside Codex, raise tool_timeout_sec for that server. Pricing pages and API documentation describe access in slightly different terms, so check the plan requirements for your own account before you depend on it.
For the text side, PicassoIA also hosts chat models such as GPT 5.6 Sol and Claude Sonnet 5, handy for drafting an AGENTS.md or comparing two approaches before you hand the task to Codex.
bearer_token_env_var or env_vars so secrets stay out of a file you might commit.npx run downloads a package, and ten seconds can be too short. Raise startup_timeout_sec./mcp. A server that silently failed to start looks exactly like a server Codex chose not to use.Pick three servers from the short list, register them, and give Codex a real task: a failing test, a stale dependency, a page that looks wrong on mobile. You will know within an hour which ones earn their place.
Then take it one step further. Open PicassoIA, generate a hero image with PicassoIA Image, and drop it into the page Codex just built. Experiment with different prompts, try the editor on the result, and see how much of a launch you can finish in a single sitting.
