Best MCP Servers for Claude Code and Codex in 2026 (Tried and Tested)

Claude Code and Codex are the two CLIs I switch between all day. Both are fast, both keep a clean /mcp view, and both let me wire in the same open protocol so my tools follow me across agents. But their base installs are quiet on purpose. They can read files, edit files, and run shell commands. That is it. The moment I want either one to pull real docs, hit a real browser, or check a real deployment, I need MCP.

Since Anthropic released the Model Context Protocol in November 2024, the ecosystem has grown to over 17,000 publicly listed servers on mcp.so. OpenAI adopted MCP for Codex in early 2025, Google DeepMind followed, and the standard was donated to the Linux Foundation's Agentic AI Foundation in December 2025. In Zuplo's State of MCP survey, 72% of users said their MCP usage will grow in the next 12 months, 70% already run 2 to 7 servers at once, and 49% cited developer productivity as the primary ROI. It is no longer an experiment.

This post is CLI-first: every install command is written twice, once for Claude Code (claude mcp add) and once for Codex (codex mcp add). Every config snippet shows the exact JSON for .mcp.json and the exact TOML for ~/.codex/config.toml. These are the best MCP servers for Claude Code and Codex I would hand someone starting today.

MCP (Model Context Protocol) is an open standard from Anthropic that lets an AI client talk to external tools and data sources through one shared interface, instead of a bespoke plugin per client.

Before MCP, every combination of AI client and tool needed its own integration: GitHub had to be wired separately for Claude, for Cursor, for ChatGPT, for VS Code. Anthropic called this the "N x M problem." MCP replaces all of that with a single JSON-RPC 2.0 protocol. You write the server once, and every compliant client (Claude Code, Codex, Claude Desktop, Cursor, Windsurf, VS Code, Cline, Gemini CLI) can use it.

The protocol defines three primitives your server can expose:

• Tools: actions the AI can invoke (run a search, deploy code, create an issue)
• Resources: data the AI can read (files, DB records, API responses)
• Prompts: reusable templates the server exposes to the client

Both Claude Code and Codex speak the two transports that cover 99% of servers:

• stdio: the server runs locally as a subprocess, the CLI starts and stops it for you
• HTTP: streamable HTTP for modern remote servers, usually with OAuth

Claude Code additionally supports SSE for older remote servers and WebSocket for servers that push events unprompted. Codex sticks to stdio and HTTP.

For a deeper protocol tour, see the MCP tutorial and the MCP vs CLI comparison.

Claude Code uses JSON under a top-level mcpServers object. Codex uses TOML under [mcp_servers.<name>] tables. Same tools, different syntax.

Claude Code (.mcp.json):

{
  "mcpServers": {
    "firecrawl": {
      "type": "http",
      "url": "https://mcp.firecrawl.dev/v2/mcp-oauth"
    },
    "playwright": {
      "command": "npx",
      "args": ["-y", "@playwright/mcp@latest"]
    }
  }
}

An entry with a url but no type is a config error in Claude Code (it reads command-less entries as stdio), so always set type on remote servers.

Codex (~/.codex/config.toml):

[mcp_servers.firecrawl]
url = "https://mcp.firecrawl.dev/v2/mcp-oauth"
 
[mcp_servers.playwright]
command = "npx"
args = ["-y", "@playwright/mcp@latest"]

Note the exact table name: mcp_servers, not mcp.servers. Codex silently skips misnamed sections.

You rarely need to edit either file by hand. Each CLI writes the config for you.

Claude Code:

# Remote HTTP with OAuth (Firecrawl, GitHub, Linear, Vercel, Sentry, Asana)
claude mcp add --scope user --transport http firecrawl https://mcp.firecrawl.dev/v2/mcp-oauth
 
# Local stdio (Playwright, Chrome DevTools, Sequential Thinking)
claude mcp add playwright -- npx -y @playwright/mcp@latest
 
claude mcp list
claude mcp remove firecrawl

--scope user writes to ~/.claude.json. Drop the flag and it defaults to local scope (private, current project only). Use --scope project to check the config into .mcp.json and share it with your team.

Codex:

# Remote HTTP with OAuth
codex mcp add firecrawl --url https://mcp.firecrawl.dev/v2/mcp-oauth
codex mcp login firecrawl
 
# Local stdio
codex mcp add playwright -- npx -y @playwright/mcp@latest
 
codex mcp list
codex mcp remove firecrawl

Codex splits registration and authentication: codex mcp add writes the config, then codex mcp login <name> opens the browser to complete OAuth. Claude Code triggers OAuth inline on first use.

Inside either CLI, /mcp shows every configured server, whether it is connected, and which tools it exposes. Codex additionally accepts /mcp verbose for server diagnostics. Use it to confirm auth worked after adding a remote server, or to spot the specific tool name when you want to prompt the agent to call one directly.

I run product marketing at Firecrawl, and I switch between Claude Code and Codex depending on the job. So this list leans two ways at once. The engineering MCPs (Chrome DevTools, Playwright, GitHub, Sentry, Vercel) come from shipping alongside the team. The research, docs, and analytics MCPs (Firecrawl, Linear, Asana, Sequel) come from the day-to-day of writing, planning, and pulling numbers without dropping into six tabs.

Every server on this list has a specific job neither Claude Code nor Codex can do out of the box, and every install block shows the command for both CLIs. If two servers cover the same job, I kept the one with the cleaner surface and the more permissive auth story.

Firecrawl exposes its web context stack (Search, Scrape, Parse, Crawl, Map, Interact, Agent, and Monitor) through the Firecrawl MCP, so both Claude Code and Codex can call every endpoint directly.

Neither Claude Code nor Codex has a reliable way to hit the live web out of the box. It can shell out to curl, but that returns raw HTML, gets blocked on most modern sites, and cannot render JavaScript. Firecrawl closes that gap in one server. It is also one of the top 50 most-starred repositories on GitHub, so this is not a niche pick.

• firecrawl_search: /search: search the live web and return full pages, not just links, with time-based filters
• firecrawl_developer_search: the tool that makes this MCP different for coding agents (more on this below)
• firecrawl_scrape: /scrape: turn any URL into clean Markdown or structured JSON, handling JS-heavy SPAs and geo-sensitive sites
• firecrawl_parse: /parse: convert PDFs and office documents into usable text via Firecrawl Parse
• firecrawl_crawl and firecrawl_map: /crawl: asynchronously crawl entire sites or discover structure fast
• firecrawl_interact: /interact: scrape a page and take actions in it (click, fill, log in, paginate) using natural language or Playwright code
• firecrawl_agent: /agent: launch an autonomous research agent that browses, searches, and compiles structured reports
• firecrawl_monitor: /monitor: watch pages for changes and pipe diffs back into the agent loop

The Firecrawl Developer Index: why this MCP is different for coding agents

firecrawl_developer_search is the tool I would install this server for even if it did nothing else. It queries the Firecrawl Developer Index, a semantic index over 70M+ developer artifacts refreshed daily: READMEs, GitHub issues, pull requests, OpenAPI specs, changelogs, and external docs sites, all crawled and embedded so Claude Code and Codex retrieve the exact artifact that answers a question, not a generic web result ranked for humans.

That distinction matters because most "web search for AI" tools return the same ten blog posts and Stack Overflow threads you get in a browser. Developer Search returns the specific PR that closed the bug, the exact issue where a maintainer confirmed the workaround, the OpenAPI spec that documents the parameter you are looking for. You can filter by types (issues, PRs, code, docs), repos, language, min_stars, and more, so a query like "how did FastAPI handle background tasks before 0.100" narrows to the right PRs instead of five years of tutorials.

The Developer Index ranked #1 overall on the DevDex benchmark, the coding-agent retrieval benchmark that scores how often a tool returns the artifact an agent actually needs. In practice inside either CLI, that shows up as fewer hallucinated APIs, fewer "let me check the docs" round-trips, and answers that cite a real PR or issue instead of a plausible-sounding paragraph. If the rest of the Firecrawl MCP tools give your coding agent a browser, Developer Search gives it a librarian.

Install:

# Claude Code, keyless (no signup, Search / Scrape / Parse only, rate-limited per IP)
claude mcp add --scope user --transport http firecrawl https://mcp.firecrawl.dev/v2/mcp
 
# Claude Code, OAuth (full tool surface, browser sign-in on first use)
claude mcp add --scope user --transport http firecrawl https://mcp.firecrawl.dev/v2/mcp-oauth
 
# Codex, keyless
codex mcp add firecrawl --url https://mcp.firecrawl.dev/v2/mcp
 
# Codex, OAuth
codex mcp add firecrawl --url https://mcp.firecrawl.dev/v2/mcp-oauth
codex mcp login firecrawl

Example prompts:

"Use firecrawl_developer_search to find the PR that fixed the WebSocket reconnect bug in socket.io, then summarize the actual change"
"Find the latest React 20 release notes and summarize the breaking changes"
"Use the Firecrawl agent to research the top 5 vector databases and return a comparison table"
"Log into staging.acme.com, navigate to /admin/reports, and extract the last 7 days of KPIs"

Honest take: This is the one MCP I refuse to work without in either Claude Code or Codex. The keyless endpoint means I can hand a Firecrawl URL to a teammate and they are searching the live web thirty seconds later, no account required. The Agent tool is genuinely useful for research prompts that would otherwise take me half an hour of tab-hopping.

Cons: Large-scale web data extraction burns through Firecrawl credits fast, so serious crawl or agent workloads need a higher-tier plan.

Repo: github.com/firecrawl/firecrawl. Full docs: Firecrawl MCP. Also see: Firecrawl's official Claude plugin.

Microsoft's Playwright MCP server gives Claude Code and Codex a real browser they can drive through the accessibility tree, not screenshots.

For anything that needs to interact with your own app (E2E scenarios, verifying a UI change, reproducing a bug that only shows up on a real browser), Playwright MCP beats screenshot-based approaches on both speed and reliability.

• browser_navigate: open URLs and follow links
• browser_click, browser_type, browser_fill_form: interact with any element by accessibility label
• browser_snapshot: return a structured accessibility snapshot of the current page
• browser_take_screenshot: full-page or element-specific PNG capture
• browser_evaluate: run arbitrary JavaScript in the page context

Install:

# Claude Code
claude mcp add playwright -- npx -y @playwright/mcp@latest
 
# Codex
codex mcp add playwright -- npx -y @playwright/mcp@latest

Example prompts:

"Navigate to localhost:3000/checkout and verify the payment form submits with test card 4242 4242 4242 4242"
"Run the signup flow and report the exact error message shown when I submit an invalid email"
"Take a screenshot of the dashboard on a mobile viewport and identify any layout issues"

Honest take: Playwright MCP is what makes "does this actually work in a real browser?" a one-line prompt instead of a manual test session. The accessibility-tree approach means Claude gets structured, labeled elements to work with, so the tool calls are consistently accurate.

Cons: First run downloads a Chromium binary, which is slow and eats disk. If you already have Chrome open with your dev session, prefer the Chrome DevTools MCP below so Claude sees the exact state of your running app instead of a fresh browser.

Repo: github.com/microsoft/playwright-mcp.

The Chrome DevTools MCP server hooks Claude Code and Codex into a live Chrome tab so they can read the console, watch the network, and pull performance traces from the app you are already running.

Playwright MCP is great for a fresh, headless browser. This one is different: it attaches to the Chrome you already have open with your dev server. Claude sees the same console errors, network waterfall, and performance profile you see.

• list_console_messages: pull console output filtered by level or search string
• list_network_requests: inspect the network waterfall, filter by URL pattern
• get_network_request: fetch a specific request's headers, body, and timing
• performance_start_trace / performance_stop_trace: capture a real profile of a user interaction
• evaluate_script: run JS in the page and get the result back

Install:

# Claude Code
claude mcp add chrome-devtools -- npx -y chrome-devtools-mcp@latest
 
# Codex
codex mcp add chrome-devtools -- npx -y chrome-devtools-mcp@latest

Example prompts:

"Check the console on the tab I have open and tell me what's throwing that TypeError"
"List all requests to /api/checkout in the last minute and show me the ones that returned 500"
"Start a performance trace, then I'll click the Buy button. Tell me what's blocking the main thread."

Honest take: This is my favorite MCP for the "why is it slow?" and "why is it 500-ing?" categories of debugging. Instead of screenshotting the DevTools panel and pasting it into Claude, I just ask.

Cons: You need Chrome running with the debug port enabled, and it only sees whichever tab is active. It also has read access to any page in that Chrome profile, so use a dedicated Chrome profile for dev work, not your personal one with logged-in accounts.

Repo: github.com/ChromeDevTools/chrome-devtools-mcp.

The official GitHub MCP server is the missing hand for anything involving repos, PRs, and issues.

Both Claude Code and Codex can already read and edit files in your working tree. GitHub MCP extends that to everything else: opening PRs, reviewing them, reading Actions logs, searching across every repo you have access to.

• Read files across branches and other repos in your org
• Open, review, and merge pull requests
• Inspect Actions runs and logs
• Create issues with proper labels, assignees, and milestones
• Search code and issues across repos

Install:

# Claude Code
claude mcp add --scope user --transport http github https://api.githubcopilot.com/mcp/
 
# Codex
codex mcp add github --url https://api.githubcopilot.com/mcp/
codex mcp login github

Example prompts:

"Open a PR from this branch to main with a summary of the changes since origin/main"
"Fetch the failing Actions run for PR #4231 and tell me which step broke"
"Search all our repos for uses of the old auth-middleware package and open issues to migrate them"

Honest take: GitHub MCP is what turns "let me open a PR" from a context switch into a single prompt. The OAuth flow uses your own GitHub permissions, so it can only do what you can do.

Cons: Actions log fetching is slower than the GitHub UI and truncates on very long jobs, so for gnarly CI failures I still open the browser to scroll the full log.

Repo: github.com/github/github-mcp-server.

The Linear MCP server connects Claude Code and Codex to your issue tracker, so ticket work stops being a separate tab.

For teams that live in Linear, this one earns its slot every day. Log a bug the moment you find it, check what is in the current cycle, move tickets to In Progress without leaving the terminal.

• Read, create, and update issues and sub-issues
• Manage labels, priorities, assignees, and statuses
• Search across projects and teams by keyword or filter
• Check cycle (sprint) status and progress

Install:

# Claude Code
claude mcp add --scope user --transport http linear https://mcp.linear.app/mcp
 
# Codex
codex mcp add linear --url https://mcp.linear.app/mcp
codex mcp login linear

Example prompts:

"Create a bug in the Backend project: /api/users returns 500 when the email contains a plus sign. Repro steps: ..."
"What tickets are assigned to me in the current cycle? Group by status."
"Mark ENG-492 as done and add a comment linking to PR #4231"

Honest take: The value here is not any single feature. It is that logging a bug the moment I hit it, instead of "I'll write that up later," happens every single time now.

Cons: The read tools return a lot of metadata per ticket by default, which can chew through the context window if you ask for a full cycle. Ask for specific fields, or filter down before you read.

Docs: linear.app/docs/mcp.

The official Vercel MCP server gives Claude Code and Codex direct access to your Vercel projects: deployments, env vars, build logs, and domain config.

For Next.js and full-stack teams that ship to Vercel, this MCP kills the "it works locally but not on Vercel" loop.

• List and inspect current deployments (production and preview)
• Fetch build logs for failed deployments
• Create and update environment variables per environment
• Trigger new deployments
• Manage domain configuration

Install:

# Claude Code
claude mcp add --scope user --transport http vercel https://mcp.vercel.com
 
# Codex
codex mcp add vercel --url https://mcp.vercel.com
codex mcp login vercel

Example prompts:

"My last production deploy failed. Pull the build logs and tell me what broke."
"Add NEXT_PUBLIC_STRIPE_KEY to the staging environment with this value"
"List all preview deployments for the feature/checkout-v2 branch"

Honest take: The build-log tool alone is worth the install. Instead of copy-pasting a Vercel log into chat, I ask Claude to fetch it and diagnose it, and I get a fix suggestion in the same round-trip.

Cons: Env var writes are surprisingly permissive by default. If you connect a Vercel account that has access to production, be explicit about which environment you want changes to land in, or scope the OAuth token to a single project.

Docs: vercel.com/docs/agent-resources/vercel-mcp.

The Sentry MCP server hooks Claude Code and Codex into your error monitoring pipeline, so stack traces come with all their context attached.

The usual debugging loop is lossy: see the error in Sentry, copy the stack trace, paste into chat, remember to also mention the environment and the recent release. With Sentry MCP, Claude gets the same view you do.

• Fetch full error context, stack traces, breadcrumbs, and related events
• Correlate errors with recent releases and deployments
• Search issues by tag, environment, time range, or error message
• Inspect performance data and transaction traces

Install:

# Claude Code
claude mcp add --scope user --transport http sentry https://mcp.sentry.dev/mcp
 
# Codex
codex mcp add sentry --url https://mcp.sentry.dev/mcp
codex mcp login sentry

Example prompts:

"Pull the top 5 unresolved Sentry issues in production tagged payment, ranked by frequency"
"For issue FRONTEND-4821, fetch the full context and suggest a fix"
"Did error rates spike after our last deploy? Check the past 2 hours."

Honest take: Once Claude has the breadcrumbs and the release context, its fix suggestions get sharply better. It also cuts down on the "give me more context" back-and-forth.

Cons: Search across all projects is slow if your org has hundreds. Filter by project or environment up front. And Sentry's own rate limits apply, so a very chatty session can hit them.

Docs: mcp.sentry.dev.

The Supabase MCP server gives Claude Code and Codex scoped, usually read-only access to a Supabase project.

If Postgres is where your product state lives, this MCP means Claude can answer questions about the data without you writing SQL by hand.

• Explore schemas, tables, and views
• Run test queries (read-only by default, opt-in for writes)
• Read auth users and storage buckets
• Deploy and inspect Edge Functions
• Scope to a single project so blast radius stays small

Install:

# Claude Code
claude mcp add supabase -- npx -y @supabase/mcp-server-supabase@latest \
  --project-ref YOUR_PROJECT_REF --read-only
 
# Codex
codex mcp add supabase -- npx -y @supabase/mcp-server-supabase@latest \
  --project-ref YOUR_PROJECT_REF --read-only

Example prompts:

"What tables reference the users table? Show the foreign key columns."
"Count how many rows in orders have status='pending' and were created in the last 7 days"
"Show me the RLS policies on the invoices table"

Honest take: Read-only Supabase MCP is one of the safest wins on this list. It answers schema questions instantly and makes "does this column already exist?" a one-line prompt.

Cons: If you flip on write access, you are one prompt away from Claude running a destructive query. Keep --read-only on for anything you care about and open a separate connection with a dedicated key when you want writes.

Docs: supabase.com/docs/guides/getting-started/mcp.

Asana ships an official remote MCP server at https://mcp.asana.com/v2/mcp that reads and updates tasks, projects, and workflows straight from Claude Code or Codex.

For teams that live in Asana, this collapses the loop between "I finished the change" and "the ticket says so." Ask either agent to update a task's status, add a comment linking the PR, or spin up follow-up subtasks in the same project, without opening the tab.

• Read tasks, comments, subtasks, and dependencies
• Update status, assignee, due date, and custom fields
• Create tasks and subtasks with descriptions, tags, and section placement
• Search by project, assignee, or custom filter
• Respect your Asana permissions through OAuth, no service account

Install:

# Claude Code
claude mcp add --scope user --transport http asana https://mcp.asana.com/v2/mcp
 
# Codex
codex mcp add asana --url https://mcp.asana.com/v2/mcp
codex mcp login asana

First use triggers OAuth in the browser, and credentials never touch .mcp.json or config.toml.

Example prompts:

"Find every Asana task assigned to me due this week and summarize them"
"Add a comment to task 12345 with the PR link and mark it as In Review"
"Create three subtasks under the 'Q3 launch' task, one per checklist item"

Honest take: Because it is an official Asana server on HTTP + OAuth, it is the lowest-friction ticket integration on this list. No API key setup, no local install, no maintenance when Asana's API changes. Pair it with a small set of Claude Code skills or Codex prompts for weekly planning and standup summaries and it starts to feel closer to the CLI than the Asana web app does.

Cons: Read-through-comments works well, but Claude will occasionally over-eagerly update task status if the prompt is loose. Scope writes tightly and confirm each one until you know how your team's field conventions map to the tool calls.

Reference: developers.asana.com/docs/mcp-server.

The Sequential Thinking MCP server is a reasoning aid, not a data source. It exposes a tool that structures Claude's chain of thought into numbered, revisable steps.

Most MCPs on this list connect Claude to something in the world. This one connects Claude to itself, more carefully. On architectural decisions, hard debugging sessions, and anything where a linear pass is too shallow, it noticeably improves the answer.

• sequential_thinking: force Claude to think in numbered steps, with branching and revision built in
• Runs entirely locally with no auth
• Adds no external state

Install:

# Claude Code
claude mcp add sequential-thinking -- npx -y @modelcontextprotocol/server-sequential-thinking
 
# Codex
codex mcp add sequential-thinking -- npx -y @modelcontextprotocol/server-sequential-thinking

Example prompts:

"Using sequential thinking, plan the migration from our monolith to a modular structure"
"Debug why the checkout flow drops session state on the third step. Think through it step by step."
"Design a rate-limiting strategy for our public API. Consider at least three approaches before picking one."

Honest take: Sequential Thinking is a nudge, not magic. On tasks where Claude would otherwise sprint to an answer that is 70% right, it earns its slot by slowing the pass down and forcing it to actually revise mid-plan.

Cons: It adds tokens to every response that uses it, so leave it off for quick edits. And on truly simple tasks the structure feels performative.

Repo: github.com/modelcontextprotocol/servers/tree/main/src/sequentialthinking.

Sequel is one MCP endpoint that fans out to Google Analytics, Search Console, Google Ads, Meta Ads, HubSpot, Stripe, Mixpanel, Amplitude, PostHog, Google Sheets, and Intercom: the marketing and revenue stack that mostly still does not ship native MCPs.

Most of the tools I actually depend on for positioning, launch analysis, and pipeline reviews still have no official MCP: Google Search Console, Google Analytics 4, Google Ads, and Meta Ads all sit outside the ecosystem, and community wrappers around them tend to break the moment Google rotates a scope. Sequel closes that gap. One sequel install claude-code command wires up a governed data layer that speaks to every source at once, learns your metric definitions and joins, and holds the credentials so Claude never touches them.

• Query GA4, Search Console, Google Ads, Meta Ads, HubSpot, Stripe, Mixpanel, Amplitude, PostHog, Google Sheets, and Intercom through one MCP endpoint
• Cross-join across sources in a single question (blended ROAS across ad platforms, CAC by channel, signups vs revenue)
• Sequel learns your team's metric definitions and vocabulary, so answers get sharper the more you use it
• Credentials live in Sequel's gateway, agents get answers not keys
• Fine-grained audit logs on every query and action

Install:

# Option A: use the Sequel CLI (creates the API key and writes the config for you)
curl -fsSL https://sequel.sh/install | sh
sequel install claude-code    # or: sequel install codex
 
# Option B: register the remote MCP server directly
# Claude Code
claude mcp add --scope user --transport http sequel https://api.sequel.sh/mcp
 
# Codex
codex mcp add sequel --url https://api.sequel.sh/mcp
codex mcp login sequel

Full install reference: sequel.sh/docs/install.

Example prompts:

"What was our blended ROAS across Google Ads and Meta Ads last month? Break it out by campaign."
"Show me the top 10 landing pages in Search Console by clicks last week, then cross-reference with GA4 conversion rate"
"Calculate CAC by channel over the last quarter using HubSpot pipeline data and Stripe revenue"
"Which of last month's signups from PostHog are still active in Mixpanel this week?"

Honest take: For anyone doing growth, marketing analytics, or revenue work in Claude Code or Codex, this is the MCP that changes what the terminal is for. Google Search Console alone is a big enough gap in the official MCP ecosystem to justify installing Sequel, and once it is in you stop exporting CSVs from four tools every Monday. The "one endpoint, many sources" pattern also means the agent figures out the joins instead of you gluing them together in a spreadsheet.

Cons: It is a paid, hosted layer, not a local MCP, so credentials, queries, and audit logs live in Sequel's cloud. That is the point of the product (governance and shared metric definitions), but if you need everything self-hosted this is not the fit. Coverage is broad on marketing and revenue tools and narrower on classic BI warehouses, so pair it with a Postgres or Supabase MCP if your source of truth is a warehouse.

Reference: sequel.sh.

Composio exposes tools for 1000+ SaaS platforms (GitHub, Slack, Gmail, Jira, Salesforce, HubSpot, Notion, and hundreds more) behind a single MCP connection, with auth managed for you.

Where Sequel is deep on marketing and revenue data, Composio is wide across SaaS. Instead of installing a separate MCP server for every app your team touches, you connect one Composio account and pick the specific apps and actions to expose. OAuth, API key storage, and token refresh happen in Composio's dashboard, so you never wire an integration by hand.

• One connection fanning out to 1000+ apps via https://connect.composio.dev/mcp
• Managed OAuth and API keys, refreshed automatically
• Per-app allowlists so Claude sees only the actions you approve
• Runs remote, no local process to babysit
• Useful for cross-app automations that span 3 or 4 tools in one prompt

Install:

# Install the Composio CLI (wires the agent plugin into Claude Code or Codex)
curl -fsSL https://composio.dev/install | sh
composio login
 
# Or register the remote MCP endpoint directly
# Claude Code
claude mcp add --scope user --transport http composio https://connect.composio.dev/mcp
 
# Codex
codex mcp add composio --url https://connect.composio.dev/mcp
codex mcp login composio

Composio's agent plugin handles the MCP registration for both Claude Code and Codex, and you pick which apps to expose from the Composio dashboard.

Example prompts:

"Check my Linear queue and for each ticket tagged urgent, create a GitHub issue and notify the #engineering Slack channel"
"Search my Gmail for unread messages about the API outage and summarize them"
"Move every Jira ticket in Ready for Review to In Progress if there's an open PR referencing it"

Honest take: For cross-app automations where the value is in the fan-out (touch Linear, then GitHub, then Slack in one prompt), Composio is the fastest way to get there without installing five separate MCPs. The dashboard-managed auth is a genuine time saver.

Cons: Because Composio is a proxy layer, you are trusting it with the credentials for every app you connect through it, so it is worth thinking about which tools you want inside the perimeter and which you would rather wire up directly (GitHub, Linear, and Vercel already have great official MCPs on this list). Keep the per-app allowlists tight or the tool schema surface grows fast, which lands right back in the token-cost tradeoff above.

Reference: composio.dev.

The honest answer: fewer than you want to install. Every MCP server you connect adds its tool schemas to Claude Code's context on every request, so the cost is not just "an extra tab" but a real hit to your token budget and, in some setups, response latency. Zuplo's State of MCP survey found 70% of MCP users run between 2 and 7 servers at once, and that range holds up in practice.

A useful rule of thumb: the tool schemas from a chatty MCP (Firecrawl, GitHub, Composio) can eat thousands of tokens before you have typed a prompt. Multiply that by five or six servers and you have burned a meaningful chunk of your context window on descriptions the agent may never call. That is the core token-efficiency problem in Claude Code (and the same math applies to Codex): the base install is quiet, but MCP overhead is where the bill sneaks up on you. And because every model counts tokens slightly differently, a schema that looks lean in one client can be 30% heavier when the model actually loads it.

Three ways to keep it honest:

• Group by mode, not by tool. Keep the 4 or 5 servers you use every day in your user scope, and put anything mode-specific (Sentry only during on-call, Vercel only on deploy days) into per-project .mcp.json files. You get the full toolbox when the work needs it and a lean surface when it does not.
• Prefer servers that return clean, minimal output. Firecrawl's markdown is deliberately compact (token-efficient scraping and search is a design goal), which matters when Claude reads the response.
• Remove what you do not call. Run /mcp inside Claude Code and be honest about which tools you have actually used in the last week. If a server has been sitting there quiet, claude mcp remove it. You can always add it back.

The starter pack I would hand a new Claude Code or Codex user is four servers: Firecrawl for the live web, GitHub for repos, Linear for tickets, and either Chrome DevTools (if you ship frontend) or Sequel (if you work in marketing or revenue). That covers the biggest gap in the base install without shredding your context budget on schemas the agent never touches.

The combination that carries me through most weeks is four servers: Firecrawl for anything on the live web, Chrome DevTools for anything on the running app, GitHub for anything involving PRs and issues, and Linear for keeping ticket state honest. That is the base stack. Everything else on this list turns on when the work turns to it.

If you are on the fence about where to start, the answer is Firecrawl. Neither Claude Code nor Codex has a reliable built-in way to hit the live web, and the keyless endpoint means you can prove it works in thirty seconds with no signup. From there, add the servers that match your friction points: Chrome DevTools if debugging burns time, Vercel if deploys are where things break, Linear if ticket hygiene is where things slip.

Two ecosystem notes worth keeping in mind. First, MCP is a portable standard. Every server on this list also works in Cursor, VS Code with Copilot, Windsurf, and Gemini CLI with a slightly different config path, so investment in one config carries over between Claude Code, Codex, and the rest. Second, discovery is now real: mcp.so, awesome-mcp-servers, and Docker's MCP Catalog are all reasonable places to browse a curated list of top Claude Code and Codex MCP servers when you want to go past what I keep installed.

If you want to go deeper on the MCP side of either agent, our Claude Code plugins roundup, the best Claude Code skills, and the Claude Code vs Codex comparison all pair with this stack. And if you would rather build your own MCP server than install someone else's, the FastMCP tutorial walks through a Python one end to end.