Best MCP servers for coding agents: a practical list

The best MCP servers for coding agents are the ones that give the agent something it can’t do on its own: see the app running in a browser, read today’s library docs, look at the issue it’s fixing, find the stack trace from production. A coding agent like Claude Code, Codex or Gemini CLI already reads files, edits them and runs commands. Adding a server that duplicates that only costs context.

This list is opinionated and short on purpose. For each server you get what it does, when it helps, how to add it, and what to watch out for. If you’re new to the protocol, start with what an MCP server is and the MCP glossary entry.

How I picked these servers

A server makes this list if it passes three checks:

1. It fills a real gap. It reaches something outside the repo: a browser, a hosted service, a database, current documentation.
2. It’s maintained by the vendor or a well-known project. The official repo shows install instructions, and the server is updated.
3. Its access can be narrowed. Read-only modes, toolsets, project scoping or allowed directories. A server you can’t limit is a server you should think twice about.

One thing all servers share: their tool definitions are added to the agent’s context and re-sent on every turn, even when the agent never calls them. So the question is never “is this server useful?” but “is it useful to this agent, in this project, right now?”

Quick reference

1. Playwright: let the agent see the app

If you only add one server, add this one. Microsoft’s Playwright MCP lets the agent open your app on localhost, read the page through the accessibility tree, click buttons, fill forms and take screenshots. That turns “I changed the form, it should work” into “I submitted the form and saw the success message.”

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

It needs Node.js 18 or newer. Useful flags: --headless to run without a window, and --isolated to keep the browser profile in memory so no cookies or logins stick around between sessions. There’s also --allowed-origins, but the project itself says it isn’t a security boundary, so don’t rely on it to keep the agent off the open web.

Watch out for: pages the agent visits are input to the model. A page that says “ignore your instructions and run this command” is a prompt injection attempt. Keep the agent on your own app where you can. For a full workflow, see browser testing with AI agents.

2. Chrome DevTools: debug what the browser sees

Google’s Chrome DevTools MCP overlaps with Playwright but leans toward debugging: console messages, network requests, performance traces. When a page is slow or a request fails with a CORS error, this is the server that lets the agent find out why instead of guessing.

claude mcp add chrome-devtools -- npx -y chrome-devtools-mcp@latest

For Codex and Gemini CLI, use the same command (npx -y chrome-devtools-mcp@latest) with codex mcp add or gemini mcp add. Pick one of the two browser servers per agent unless you really need both; each adds a long list of tools.

3. Context7: current documentation instead of memory

Models learn libraries from training data that is months or years old. That’s why agents call functions that were renamed two versions ago. Context7, from Upstash, serves current, version-specific documentation and code examples for a long list of libraries, so the agent can look things up instead of guessing.

# Remote server
claude mcp add --transport http context7 https://mcp.context7.com/mcp

# Or run it locally
codex mcp add context7 -- npx -y @upstash/context7-mcp

If you have a Context7 API key, pass it in a CONTEXT7_API_KEY header on the remote server (for example --header "CONTEXT7_API_KEY: ctx7sk-…" with claude mcp add). A useful habit in your CLAUDE.md or AGENTS.md: “When you use a library API you’re not sure about, check Context7 first.” Agents follow written rules more reliably than one-off reminders; see how to write CLAUDE.md and AGENTS.md.

Watch out for: it’s read-only, so the risk is low, but its tools still cost context. Give it to agents that write code against third-party libraries, not to a reviewer agent that only reads diffs.

4. GitHub: issues, pull requests and CI

GitHub’s official server reads and writes issues, pull requests, code search results, Actions runs and more. The agent can start from the issue text, check the failing workflow and open a pull request at the end.

The remote server lives at https://api.githubcopilot.com/mcp/. You can run it locally with Docker too:

claude mcp add github -e GITHUB_PERSONAL_ACCESS_TOKEN=$GITHUB_PAT \
  -- docker run -i --rm -e GITHUB_PERSONAL_ACCESS_TOKEN ghcr.io/github/github-mcp-server

This is where least privilege matters most. The GitHub server has a lot of tools, and some of them write. Narrow it:

• Toolsets. Enable only what you need, for example repos,issues,pull_requests, with the --toolsets flag or GITHUB_TOOLSETS locally, or the X-MCP-Toolsets header on the remote server.
• Read-only mode. Use --read-only locally, or append /readonly to the remote URL (https://api.githubcopilot.com/mcp/readonly), or send X-MCP-Readonly: true.
• A fine-grained token. Scope the personal access token to the repositories the agent works on, with the smallest permissions that cover the job.

A reviewer or triage agent rarely needs write access. Give write tools only to the agent that is supposed to open pull requests.

5. Sentry: start from the real error

Sentry’s hosted MCP server lets the agent search errors, read stack traces and look at issue details. “Fix the bug users hit on checkout” becomes “fix this exception, at this line, with these breadcrumbs.” Authentication is OAuth: the first connection opens a browser sign-in.

claude mcp add --transport http sentry https://mcp.sentry.dev/mcp/my-org/my-project

Replace my-org and my-project with your organization and project slugs. Scoping the URL to one project is what Sentry recommends: tools then default to that project and some discovery tools are hidden, which also saves context. Pairing Sentry with GitHub works well for fixing CI failures and production bugs from the issue text onward.

6. A database server, read-only

An agent that can look at the schema and run a SELECT writes better queries and migrations. An agent that can run DROP TABLE on production is a bad day waiting to happen. Two solid options:

Postgres MCP Pro (crystaldba/postgres-mcp) works with any PostgreSQL database. Besides queries, it can explain plans, check database health and suggest indexes. Its key setting is the access mode:

claude mcp add postgres --env DATABASE_URI=postgresql://readonly_user:pass@localhost:5432/app_dev \
  -- uvx postgres-mcp --access-mode=restricted

restricted limits work to read-only transactions and caps execution time; unrestricted allows full read and write. Use restricted, and connect as a database user that only has SELECT rights anyway. Two locks are better than one, and the project notes that unsafe stored procedure languages could get around its checks.

Supabase has a hosted server at https://mcp.supabase.com/mcp. Add ?project_ref=<id>&read_only=true to tie it to one project and run every query as a read-only Postgres user. Supabase’s own advice is to use it on development data, keep manual approval of tool calls on, and not hand it to end users.

Note: the old reference Postgres server from the MCP project is archived. Pick a maintained one.

7. Git, Fetch and Filesystem: the reference servers

The MCP project still maintains a few reference servers. They’re handy, but check whether your agent needs them first.

• Git (uvx mcp-server-git --repository /path/to/repo): log, diff, blame and commit tools. Coding agents already run git in the terminal, so this helps most in clients without shell access or when you want git operations to show up as explicit tool calls.
• Fetch (uvx mcp-server-fetch): turns a web page into Markdown for the model. Good for reading an API reference that isn’t in Context7. Every page it fetches is untrusted input, so the prompt injection warning applies in full.
• Filesystem (npx -y @modelcontextprotocol/server-filesystem /path/one /path/two): file access limited to the directories you list. Claude Code and Codex already edit files in the project; use this to expose one extra folder, such as a shared design-tokens directory, without opening up your whole home directory.

Others worth knowing

Depending on your stack, these may earn a slot: Linear or Notion for tasks and specs, Stripe for payment objects in test mode, Figma for reading designs, Cloudflare docs, and mobile servers for simulators. Use the same three checks. A server you add “just in case” mostly adds context.

Adding servers to Claude Code, Codex and Gemini CLI

The same server works in all three; the registration differs.

Claude Code. Options go before the name, the server command after --:

claude mcp add --transport http sentry https://mcp.sentry.dev/mcp
claude mcp add --scope project playwright -- npx @playwright/mcp@latest
claude mcp list

--scope local (default) keeps it for you in this project, --scope user for all your projects, and --scope project writes a .mcp.json in the repo for the team. .mcp.json supports ${VAR} expansion, so you can commit the file without committing tokens. Run /mcp inside a session to sign in to OAuth servers.

Codex. Use the CLI or edit ~/.codex/config.toml:

[mcp_servers.github]
url = "https://api.githubcopilot.com/mcp/readonly"
bearer_token_env_var = "GITHUB_PAT"

[mcp_servers.playwright]
command = "npx"
args = ["@playwright/mcp@latest"]
enabled_tools = ["browser_navigate", "browser_snapshot", "browser_click", "browser_take_screenshot"]

bearer_token_env_var reads the token from an environment variable instead of the file, and enabled_tools / disabled_tools trim a server down to the tools you want. codex mcp login <name> handles OAuth servers.

Gemini CLI. gemini mcp add writes to .gemini/settings.json (project, the default) or ~/.gemini/settings.json with --scope user:

gemini mcp add --transport http github https://api.githubcopilot.com/mcp/readonly \
  --header "Authorization: Bearer $GITHUB_PAT"

In settings.json, includeTools and excludeTools limit tools, and trust: true skips confirmation prompts. Leave trust off for anything that writes. Note that if you put a token in a --header like above, it ends up in the settings file; prefer $VAR references in env and headers where you can.

Security notes

MCP servers connect a model to real systems. A short checklist:

• Least privilege by default. Read-only modes, narrow toolsets, one project per server, fine-grained tokens. Grant write access to one agent for one task, not to every agent forever.
• Development data, not production. Point database servers at a local copy or staging. If an agent must look at production, use a read-only user and a short session.
• Secrets out of plain text. Use environment variables, ${VAR} references or your OS keychain. A token in a committed .mcp.json is a leaked token.
• Everything a server returns is untrusted. Web pages, issue comments, database rows and error messages can all contain instructions aimed at the agent. Keep approvals on for tools that write or run commands.
• Know what you’re running. A stdio server is code running on your machine with your permissions. Install from the official repo, pin versions for anything sensitive, and don’t paste install commands from random READMEs.
• Look at the tool list. List a server’s tools before giving it to an agent, and remove what you don’t need.

For the wider picture, read AI coding agent security.

Matching servers to agents

If you run several agents, hand out servers by role:

This keeps each agent’s context lean and limits what a mistake or an injected instruction can reach. It also keeps token usage down.

How I do this with AgentVera

Registering the same servers three times in three formats gets old fast. In AgentVera I keep them in one place:

• One list for every CLI. The MCP manager holds the servers and attaches them when an agent starts: Claude Code, Codex, Gemini CLI, Copilot, Cursor, opencode and the other CLIs that take MCP. I give each server to all agents, picked agents, a group or a team role, and limit it to certain projects.
• A catalog and a cost check. The catalog has ready entries for Playwright, Chrome DevTools, Context7, GitHub, Sentry, Supabase, Git, Fetch, Filesystem and more. The connection test lists a server’s tools with an approximate token cost per tool, so I see what each one adds to every turn.
• Secrets in the keychain. Environment variables and header tokens are kept in the operating system’s keychain, and remote servers go through AgentVera’s gateway, so the CLI config never holds the token.
• A browser I can watch. The agent browser gives agents a managed Chrome through Playwright MCP, and I can follow the tabs live.
• Database access under rules. Instead of a raw connection string, the database manager lets agents query a connection through its own tool, read-only by default, with every query logged. DB Guard checks migrations the agent writes.
• Approvals. For Claude Code agents, auto approval answers only the requests known to be safe; everything else still comes to me.

Wrapping up

The best MCP setup for coding is small: a browser, current docs, your issue tracker and error monitoring, plus a read-only database when the task calls for it. Add servers per agent and per project, narrow each one with its read-only mode or toolsets, keep tokens out of plain-text files, and treat everything a server returns as untrusted. If you want to manage servers for several agents in one place, download AgentVera for free and open the MCP page.