Best MCP servers for Codex in 2026

TL;DR. The best Codex MCP servers in 2026 are the official, remote ones that do one job well: GitHub for repos and CI, Supabase or Hatchable for a database and a live app, Playwright for a browser, Context7 for current docs, Sentry for errors, Linear and Notion for the team's work, Stripe for payments, Cloudflare for edge infrastructure. Add a remote server with codex mcp add <name> --url <url>, sign in with codex mcp login <name>, or write two lines in ~/.codex/config.toml. Where a vendor ships a Codex plugin, the plugin does the same setup for you.

How this list of Codex MCP servers was chosen

Codex (CLI, desktop app and IDE extension) speaks MCP, so any server on the usual lists will connect. This one is ten, picked on four rules. The vendor's own server beats a community fork, because it tracks the product's API. Remote Streamable HTTP with OAuth beats a local process with a token in a file: nothing to install, nothing to leak. Each server has to do one job you can name. And each has a documented Codex install, so each one-liner is the vendor's shape, not ours.

General characterisations based on public information as of August 2026; check each vendor for current details.

Two shapes cover every server below: from the terminal, one add and (for OAuth) one login, with a local server's launch command after the double dash; or a [mcp_servers.name] table with a url in ~/.codex/config.toml (or a project's .codex/config.toml). If your build rejects --url, the config.toml two-liner works everywhere. First time? How to add an MCP server to Codex covers both routes, and what MCP is covers the protocol.

The best Codex MCP servers in 2026

1. GitHub MCP server (source control and CI)

Good for: issues, pull requests, code search, and Actions logs pulled into the thread so Codex can fix a red build without you pasting anything. GitHub's official server, hosted by GitHub, with toolsets you can narrow and a read-only mode.

codex mcp add github --url https://api.githubcopilot.com/mcp/ --bearer-token-env-var GITHUB_PAT_TOKEN

Caveat: GitHub's Codex guide authenticates the remote server with a personal access token in an environment variable, not OAuth, as of August 2026. Keep it fine-grained and never paste it into config.toml itself.

2. Supabase MCP server (hosted Postgres)

Good for: an app whose backend already lives on Supabase. Codex can inspect the schema, run SQL, write migrations, manage branches, deploy edge functions and read logs through one remote endpoint with OAuth sign-in.

codex mcp add supabase --url "https://mcp.supabase.com/mcp?read_only=true"
codex mcp login supabase

Caveat: real queries against a real project. Supabase's docs recommend a development project rather than production and keeping read_only=true on until you need writes. Treat every write tool as a deploy.

3. Hatchable (build, deploy, host, and a database)

Good for: when Codex should build the whole app and put it live, not just talk to a backend you already run. One OAuth sign-in, no API key, and Codex can create a project, write the files, deploy, and hand back a live URL at your-app.hatchable.site. Every project comes with its own private Postgres database, sign-in for the app's users, email, scheduled jobs and file storage. The free plan is unlimited private projects and one published app, no card. The fastest route is the plugin: open Plugins in the Codex app (or run /plugins in the CLI), install Hatchable, approve the sign-in. Manual route, same server:

[mcp_servers.hatchable]
url = "https://hatchable.com/mcp"

then codex mcp login hatchable and approve on hatchable.com.

Caveat: it hosts web apps written in HTML, JavaScript, SQL and TOML on its own platform (tool list on the MCP feature page); it is not a Python or Docker host and does not run long-lived processes, so a Flask service or a Discord bot belongs elsewhere. Both routes are spelled out in connect Codex to Hatchable.

4. Playwright MCP (browser automation)

Good for: letting Codex check its own UI work: navigate, click, fill forms, take screenshots, all through accessibility snapshots so the model reads the page structurally instead of guessing from pixels. Microsoft maintains it.

codex mcp add playwright -- npx @playwright/mcp@latest

Caveat: a local stdio server: Node.js 20 or newer, a real browser on your machine (headed by default; --headless to hide it), and a persistent profile unless you pass --isolated. A cold npx start can be slow; Codex's startup_timeout_sec setting exists for that. A browser that remembers your logins is one the agent can use; mind where you point it.

5. Context7 (current library docs)

Good for: version-specific documentation pulled into context at the moment Codex needs it, which tends to cut the "that API changed two releases ago" class of bug. Remote endpoint, optional API key.

codex mcp add context7 --url https://mcp.context7.com/mcp

Caveat: coverage depends on whether a library is indexed, and Context7's docs describe tighter rate limits without a key (set it through http_headers in config.toml). A second opinion, not a substitute for reading the source when it matters.

6. Sentry (errors and performance)

Good for: production bugs: Codex pulls the latest unhandled exception, reads the stack trace and release, and proposes the fix in the same thread. OAuth, and the URL can be scoped to one org or project.

codex mcp add sentry --url https://mcp.sentry.dev/mcp
codex mcp login sentry

Caveat: only useful for apps that already report to Sentry, and error payloads often carry user data that then flows into the model's context. Scope the URL to the project you are working on.

7. Linear (issue tracking)

Good for: "implement ENG-4521" without opening a browser. Codex reads the issue, updates status, leaves comments and creates follow-ups. Linear added initiatives, milestones and project updates in early 2026 and documents the Codex command directly.

codex mcp add linear --url https://mcp.linear.app/mcp
codex mcp login linear

Caveat: writes land in your real workspace. Linear documents a read-only endpoint at /mcp/readonly, and its older SSE endpoint is deprecated in favour of /mcp.

8. Notion (specs and internal docs)

Good for: reading the PRD, runbook or meeting notes that explain why the code is the way it is, and writing pages back. OAuth only; Notion's docs give the Codex setup as a config.toml entry plus a login.

[mcp_servers.notion]
url = "https://mcp.notion.com/mcp"

then codex mcp login notion.

Caveat: Notion's docs say the OAuth flow must be completed interactively, and the server reads whatever the signed-in account can read, so sign in with the account whose visibility you mean to grant.

9. Stripe (payments)

Good for: a payments integration with the real API in reach: search Stripe's docs, read customers, subscriptions and invoices, create products, prices and payment links. OAuth by default, or a restricted key through bearer_token_env_var.

[mcp_servers.stripe]
url = "https://mcp.stripe.com"

then codex mcp login stripe.

Caveat: write tools move real money (refunds, subscription changes). Stripe's docs say to keep human confirmation of tools on and be cautious running it beside other servers, since a prompt injection elsewhere can reach it. Start in a sandbox.

10. Cloudflare (edge infrastructure and docs)

Good for: Workers and Pages projects. Cloudflare ships small remote servers: documentation for accurate platform answers, Workers Bindings to create KV, D1 and R2 resources, Observability for logs and analytics.

codex mcp add cloudflare-docs --url https://docs.mcp.cloudflare.com/mcp

Caveat: the docs server needs no sign-in; the account-level servers (bindings, observability and the rest) use OAuth and each adds its own tools. Add the two or three you use, not the full catalogue.

Codex MCP servers compared

How to pick a Codex MCP server

Start from a gap, not a list. The right server is the one whose data you keep pasting into the thread: stack traces, Sentry; the ticket, Linear; apps that get built and then sit on your laptop, a server that can deploy.

Plugin first, then config. A Codex plugin (Hatchable ships one; Stripe documents one too) wraps the same MCP server with its own setup and sign-in, so there is nothing to type. codex mcp add and config.toml are for everything else and for locked-down machines without the plugin directory.

Prefer remote and OAuth. A remote HTTP server has nothing to install or keep running, and codex mcp login <name> keeps credentials out of files; when a vendor only offers a token, bearer_token_env_var keeps the secret in your shell. Check status with codex mcp list, and start a fresh thread after authenticating so Codex re-reads the tool list.

Trim the tools. Codex lets you set enabled_tools or disabled_tools per server in config.toml. A server with forty tools of which you need six is context spent and surface area opened for nothing.

Two sensible starter kits. Maintaining an existing codebase: GitHub, Sentry, Linear, Context7, Playwright. Shipping new apps from a prompt: Hatchable for build, deploy and database, GitHub for the repo, Playwright to check the result. The same servers work in Claude Code and Cursor; only the install command changes.