Best MCP Servers for Coding Agents

For most developers the best first MCP servers are GitHub (repos and pull requests), Context7 (current library docs) and a browser server such as Playwright or Chrome DevTools (to check front-end work). Add Serena for large codebases and Sentry for error data if you use them. This shortlist is editorial, built from each project's own docs and repo, checked on 31 October 2026.

How we picked

We do not have a benchmark, and we will not pretend we do. "Best" here means a server that scores well on these checks, all of which you can verify yourself:

Where a popular server failed a check, we say so. The reference repo from the MCP project is itself clear that its servers are educational examples, not production-ready, so we treat those as "good for learning" rather than "best".

The shortlist at a glance

The rank reflects how often we would expect a developer to need it, not quality. A tiny read-only server can be more useful than a big one.

1. GitHub MCP: the first one to add

If your code lives on GitHub, start here. It lets the agent read code, search repositories, open and review pull requests, read failed job logs and check security alerts. GitHub hosts it, you can run it in Docker, and it is MIT licensed.

What makes it a good server is the control surface: toolsets you can switch on one by one (the default five are context, repos, issues, pull_requests and users), a read-only flag, and a lockdown mode for public repos. Use a fine-grained token limited to the repositories you need.

Watch for: write tools, including file deletion and repository deletion in the repos toolset, and prompt injection through issue text. Start with --read-only. Full detail on our GitHub MCP page.

claude mcp add --transport http github https://api.githubcopilot.com/mcp/ \
  -H "Authorization: Bearer $GITHUB_PAT"

2. Context7: stop the agent guessing APIs

Context7 puts up-to-date, version-specific documentation into the agent's context. It has two MCP tools, resolve-library-id and query-docs, and the code is MIT licensed. The free plan allows 1,000 API calls a month for public repositories; Pro is $10 a seat per month, per the pricing page.

It is the safest server on this list to try first because it only reads public documentation. Watch for: quota use (a question can take two calls), and the fact that docs in the index are community contributed, which the README says it cannot guarantee for accuracy. See our Context7 MCP page.

codex mcp add context7 -- npx -y @upstash/context7-mcp

3. Playwright MCP: eyes for your front end

Microsoft's Playwright server lets an agent open a page, read it as an accessibility snapshot, click, type, upload files, emulate dark mode and read console and network logs. It is Apache-2.0 and needs Node.js 18 or newer.

Watch for: the persistent browser profile keeps logins, the README says it is not a security boundary, and Playwright's own docs suggest a CLI plus skills for coding agents that care about tokens. Use --isolated on public pages. See our Playwright MCP page.

claude mcp add playwright npx @playwright/mcp@latest

4. Chrome DevTools MCP: performance and debugging data

Google's Chrome DevTools MCP is a different angle on the browser job. Its README says it exposes the content of the browser instance to the client, so the agent can inspect, debug and modify data in the browser or DevTools. The first prompt it suggests is a performance check: "Check the performance of https://developers.chrome.com", which should open the browser and record a trace.

It is Apache-2.0, needs a current LTS Node.js and current stable Chrome, and officially supports Google Chrome and Chrome for Testing only.

Watch for: two disclosures in the README. Google collects usage statistics for the tool, independent of Chrome's own, and performance tools may send trace URLs to the CrUX API unless you pass --no-performance-crux. Read both before you use it on private pages.

{
  "mcpServers": {
    "chrome-devtools": {
      "command": "npx",
      "args": ["-y", "chrome-devtools-mcp@latest"]
    }
  }
}

Choose Playwright for flows and cross-browser checks, Chrome DevTools for performance and debugging in Chrome.

5. Serena: when the repo is big

Serena gives the agent IDE-style tools: find a symbol, list its references, rename it, replace one function body. It supports 40+ languages through language servers. It takes more setup than most (uv, a serena init, a context flag per agent), and the application is GPL-3.0-or-later while its language server layer is MIT.

Watch for: the licence if you embed it in a product, and the maintainers' advice not to install it from a marketplace, because those listings can carry outdated commands. See our Serena MCP page.

6. Sentry: bring the error to the agent

Sentry hosts its server at https://mcp.sentry.dev/mcp. Point your client at it, sign in and the agent can read issues and stack traces, then go find the code. The MCP project's own architecture docs use it as the example of a remote server over Streamable HTTP.

Watch for: the older reference Sentry server is archived, so skip tutorials that point at it. Stack traces can contain user data, so decide what the agent is allowed to see. See our Sentry MCP page.

7. Supabase: great on a dev project, careful elsewhere

Supabase hosts its server at https://mcp.supabase.com/mcp, and signs you in through your client. The README's own example URL shows the options that matter: project_ref scopes the server to one project, read_only=true blocks writes, and features= limits which tool groups load.

Watch for: the README tells you to read Supabase's security best practices before you connect, because you are linking an LLM to your database. Use a development project and read-only mode first. See our Supabase MCP page.

{
  "mcpServers": {
    "supabase": {
      "type": "http",
      "url": "https://mcp.supabase.com/mcp?project_ref=YOUR_REF&read_only=true"
    }
  }
}

8. Stripe: for payment code

Stripe hosts a remote server at https://mcp.stripe.com with OAuth, per its repo. It is for people building on Stripe who want the agent to look things up and work against their account.

Watch for: money. Use a test-mode account and a restricted key, and keep write actions behind approval. See our Stripe MCP page.

9. Slack: only if you can get it

Slack's server is official and hosted, with admin approval, audit logs and per-tool rate limits. The catch is reach: clients must be backed by a registered Slack app, and Slack lists Claude Code, Cursor, Claude.ai and Perplexity as partner clients. Codex gets the skills plugin only. See our Slack MCP page.

10. Fetch and the reference servers: simple and useful

The MCP project keeps a handful of reference servers: Everything, Fetch, Filesystem, Git, Memory, Sequential Thinking and Time. Fetch turns a web page into text for the model and runs with uvx mcp-server-fetch. Filesystem restricts access to directories you list on the command line. Memory keeps a knowledge graph and starts with npx -y @modelcontextprotocol/server-memory.

They are good for learning how MCP works and for light jobs. The README says they are not production-ready, so read the code before you point one at anything important. Pages: Fetch, Filesystem, Memory, Sequential Thinking, Git.

Starter sets by role

How to tell whether a server earns its place

A server that looks useful on day one can turn out to be dead weight by day ten. Run a short trial for each one you add, and keep the result in writing.

If a server fails two rows, remove it. Removal is cheap, and you can add it back the day you need it. A short list of servers you use beats a long list you half remember.

Combinations that need care

Servers are safest alone and riskiest in combination. The risk comes from three properties meeting in one session.

1. Private data. The agent can read something sensitive, such as a database, a private repository or an inbox.
2. Untrusted content. The agent reads text that someone else wrote, such as web pages, issues, support tickets or messages.
3. A way out. The agent can send data somewhere, by posting a message, opening an issue, calling a URL or writing to a public place.

If all three are available at once, a hidden instruction in the untrusted text can ask the agent to read the private data and send it out. Each server on its own may be fine. Fetch plus a database server plus Slack is the combination to avoid. Some examples from this list:

The fix is rarely to avoid servers entirely. Break one of the three properties: limit the data, avoid reading untrusted text in that session, or remove the way out. Approval prompts help as a last brake, but people approve quickly, so rely on structure first.

A one-week plan to build your setup

1. Day 1. Add GitHub MCP with read access, and use it for one real review.
2. Day 2. Add Context7 and ask for code against a library you use. Check the answer against current docs.
3. Day 3. Add the server for your biggest daily pain, such as Playwright for front-end work or Sentry for production errors.
4. Day 4. Read the tool list for each server, and turn off any you will not use.
5. Day 5. Review the call log. Remove anything the agent has not used.
6. Weekend. Write the approved list into your repository, with versions and owners.

Stop at three or four servers. The starter sets above give a role-based shortlist, and the install checklist covers the details of each connection. For the wider field, see the MCP server list and awesome MCP servers.

Servers we left off, and why

• Old reference servers for GitHub, GitLab, Google Drive, PostgreSQL, Puppeteer, Redis, Sentry, Slack and SQLite. They are archived. Use the vendor's current server.
• Anything with no recent activity. We looked at the last push date. A server that has not moved in months may not follow the current protocol.
• Servers that only wrap a CLI you already have. If gh or psql is installed, the agent can call it with fewer tokens.
• Huge all-in-one servers. More tools mean more context and more things the agent can do wrong.

For the wider list, see Awesome MCP servers, the MCP server list and free MCP servers.

Install checklist

1. Pick one job. Install one server for it.
2. Read the tool list before you approve anything.
3. Create the narrowest token that works.
4. Turn on read-only mode if the server has one.
5. Run it for a week and look at your context usage.
6. Add the next server only if you reached for the last one.
7. Pin versions in any config you commit.

Not sure about the config format for your agent? See the MCP servers hub, which gives the same server in Claude Code, Cursor, Codex, Gemini CLI and VS Code.

Our take

This list is a reading of documents, not a test. We did not run each server against a benchmark, and we do not publish scores because we have none.

If we could keep only three, they would be GitHub, Context7 and one browser server. They cover code, knowledge and verification, which is the loop most coding work follows. Everything else is for a specific job, and that is the point: the best server is the one that matches something you do every week.

We lean toward hosted servers with OAuth for services and local servers only when files are involved. A hosted server from the vendor is maintained by the people who own the API, and OAuth lets you revoke access without hunting for a token in a dotfile. The cost is that you depend on the vendor's availability and terms.

Be wary of lists with hundreds of entries. A directory can show you what exists, but it cannot tell you what is maintained, safe or worth the context. Use it to find candidates, then run our checks.

Frequently asked questions

What are the best MCP servers to start with? GitHub, Context7 and a browser server.

How many should I install? Three or four tied to weekly jobs.

Are the best MCP servers free? Most are open source. Hosted services depend on your account with the vendor.

Which are safest to try first? Read-only ones such as Context7 and Fetch, and GitHub in read-only mode.

Do they work outside Claude Code? Yes. The config format differs by agent.

*Product names are used descriptively. We are not affiliated with any server vendor named here.*