The best MCP servers for coding agents in 2026, ranked by workflow

TL;DR

• An MCP server gives a coding agent tools for one outside system. The useful question is not how many tools it has but what it lets the agent verify or change, and what it costs in context and risk.
• The GitHub MCP Server ranks first: it covers the review loop every agent touches, and its toolsets, read-only mode and lockdown mode let you trim both context cost and blast radius.
• Context7, Playwright MCP and Chrome DevTools MCP follow, because current documentation and a real browser fix the two most common failures of generated code: stale APIs and untested UI.
• Sentry, Serena, Supabase, Linear, Figma and Terraform complete the ten. Each is strong inside one workflow and unnecessary outside it.
• Every server here can be configured read-only or scoped to one project or toolset. Use that. Tool results from issues, web pages and database rows are a prompt-injection channel, and local servers run with your privileges.

A coding agent on its own can read the repository it was opened in and run shell commands. It cannot see the pull request a teammate left comments on, the error that fired in production an hour ago, the database schema in staging, or the design the feature is meant to match. Model Context Protocol (MCP) servers close that gap: each one wraps an outside system as a set of tools the agent can call. This guide ranks ten MCP servers for coding agents such as Claude Code, Cursor, Codex, GitHub Copilot in VS Code and Devin Desktop (the editor formerly called Windsurf), judged by what they add to a developer’s workflow rather than by popularity. Capabilities, licences and limits come from each maintainer’s documentation and repository as read in early October 2026. No server was benchmarked for this piece, and no token counts below were measured by The Frontier Wire.

What an MCP server adds to a coding agent

An MCP server is a program that exposes tools, resources or prompts to an AI application over the Model Context Protocol. The specification defines three roles: the host (the agent application, such as an IDE), the client (the connector inside it) and the server. Servers run in one of two ways. A local server is launched by the client as a child process and talks over standard input and output (stdio). A remote server runs elsewhere and is reached over Streamable HTTP, usually with OAuth sign-in.

For a coding agent, the value of a server falls into three kinds of work:

• Context the model lacks. Current library documentation, a ticket’s acceptance criteria, a design’s spacing values, a stack trace from production.
• Verification the model cannot do alone. Loading the page it just changed in a real browser, reading the console, recording a performance trace.
• Actions outside the repository. Opening a pull request, updating an issue, running a migration on a database branch, triggering a Terraform run.

The first kind is low risk. The second is moderate, because a browser session can carry cookies and visit hostile pages. The third is where most of the danger sits, and the specification’s own security principles put it plainly: “Tools represent arbitrary code execution and must be treated with appropriate caution,” and “Hosts must obtain explicit user consent before invoking any tool.” It adds that tool annotations “should be considered untrusted, unless obtained from a trusted server,” and that MCP “cannot enforce these security principles at the protocol level.” Each server in this list is judged partly on how much of that caution it builds in.

A companion piece, the guide to MCP servers for business systems, covers servers for CRMs, documents and messaging. This one stays inside the software delivery loop.

How the servers were chosen

The criteria below were fixed before the ranking and are published so a reader can weight them differently. The candidate pool covered about fifteen servers, including Docker’s, Cloudflare’s, Vercel’s, AWS’s, Neon’s and the reference Git and filesystem servers.

Some candidates fell out on the first criterion. The reference Git and filesystem servers duplicate what Claude Code, Codex and Cursor already do natively through their own file and shell tools. Docker’s MCP tooling is better understood as a way to run other servers in containers, and it is covered in the MCP gateway comparison. Cloudflare, Vercel, AWS and Neon all publish capable servers, but each matters only to teams on that platform. Terraform took the infrastructure slot because it spans clouds.

The ten servers at a glance

Repository access and documentation

The two highest-ranked servers address the most common gaps: the agent cannot see the collaboration around the code, and it does not know which version of a library’s API is current.

1. GitHub MCP Server

The GitHub MCP Server is GitHub’s own, released under the MIT licence. It runs as a hosted endpoint at api.githubcopilot.com/mcp/, which GitHub describes as “the easiest method for getting up and running,” or locally from the ghcr.io/github/github-mcp-server Docker image or a Go binary. Authentication is OAuth in the browser, with tokens kept “in memory only,” or a personal access token in GITHUB_PERSONAL_ACCESS_TOKEN, which takes precedence when set.

What it lets the agent do is the reason it ranks first: read issues and review comments, open and update pull requests, search code across repositories, and, with further toolsets, inspect Actions runs, code-scanning alerts and Dependabot findings. That is the review loop almost every coding agent ends up in.

Tool-definition cost is also where it needs the most care. The repository counts more than 100 tools across 20-plus toolsets, so loading everything is expensive. By default only five toolsets are on (context, repos, issues, pull_requests and users), and the README states that enabling only what you need “can help the LLM with tool choice and reduce the context size.” On the remote server, a URL path such as /x/issues/readonly loads one toolset read-only, and headers (X-MCP-Toolsets, X-MCP-Readonly) do the same for combinations.

The server also ships a control aimed at the best-documented MCP attack. Lockdown mode hides public issue details “created by users without push access,” which is the vector Invariant Labs used in 2025 (see the risks section below). GitHub calls it “a best-effort content filter, not a security boundary.”

Limits: the full catalog is large, write tools are on by default, and a broadly scoped token gives an injected instruction reach across every repository the user can see. Best fit: every team on GitHub, starting from /readonly and adding write toolsets deliberately.

2. Context7

Context7, from Upstash, fetches current, version-specific documentation for a library and places it in the agent’s context. The MCP server is MIT-licensed, but the README is explicit that “the supporting components (API backend, parsing engine, and crawling engine) are private,” so the open-source part is a client for a hosted index. The hosted endpoint is mcp.context7.com/mcp, and a free API key from the Context7 dashboard is recommended “for higher rate limits.”

Its tool surface is the smallest in this list: two tools, resolve-library-id and query-docs. That makes it nearly free to leave connected. It is also read-only, which removes the write risk entirely. Upstash now offers a second mode in which a skill teaches the agent to call a ctx7 command-line tool instead of MCP.

Limits: the documentation index is “community-contributed,” and the project states it “cannot guarantee the accuracy, completeness, or security of all library documentation.” That means retrieved text is untrusted input like any web page. The backend cannot be self-hosted. Best fit: anyone whose agent keeps writing code against an API that changed after the model’s training cut-off.

Browser automation and debugging

An agent that edits a front end without loading it is guessing. Two browser servers, one from the Playwright team and one from the Chrome DevTools team, let it check its work. They overlap, and most developers need one, not both.

3. Playwright MCP

Playwright MCP is Microsoft’s Apache 2.0 server for driving a browser. Its design choice is to give the model “structured accessibility snapshots, bypassing the need for screenshots,” so the agent reads the page as a tree of labelled elements rather than interpreting pixels. It installs with one npx @playwright/mcp@latest entry and is documented for VS Code, Cursor, Claude Desktop, Copilot, Cline and others.

Capabilities are opt-in through --caps: core automation by default, with vision (coordinate clicks), PDF, DevTools, storage, network mocking and testing assertions as extras. With everything on, the repository counts more than 60 tools, which is a reason to keep the defaults.

Microsoft is candid about the context cost. Its README says that for coding agents, the Playwright CLI with skills is often preferred because “CLI invocations are more token-efficient: they avoid loading large tool schemas and verbose accessibility trees into the model context.” The MCP server keeps its place for “persistent state, rich introspection, and iterative reasoning.”

Limits: the README states that Playwright MCP “is not a security boundary.” The --allowed-origins and --blocked-origins flags filter requests but “do not serve as a security boundary” either. A page the agent visits can contain text that tries to redirect it. Best fit: end-to-end checks and test generation across Chromium, Firefox and WebKit.

4. Chrome DevTools MCP

Chrome DevTools MCP, maintained by the Chrome DevTools team under Apache 2.0, gives an agent the debugging half of the browser. It can record performance traces and “extract actionable performance insights,” inspect network requests, read console messages “with source-mapped stack traces,” take screenshots, and automate input through Puppeteer.

The tool reference lists 55 tools across eleven categories, from input automation to heap-memory analysis. Several categories, such as extensions, PWA and experimental third-party tools, sit behind their own flags, and a --slim mode exposes a lighter set for basic browsing. That makes the default footprint smaller than the headline count.

Limits: the README warns that the server “exposes content of the browser instance to MCP clients allowing them to inspect, debug, and modify any data,” so it should not run against a browser profile holding real sessions. Usage statistics (success rates, latency and environment information) are sent to Google by default; --no-usage-statistics turns that off. Only Chrome and Chrome for Testing are officially supported. Best fit: front-end performance and runtime debugging, where the question is why something is slow or broken rather than whether a flow passes.

Production errors and code navigation

The next two servers serve opposite ends of the loop: one brings production evidence into the editor, the other helps the agent move through a large codebase without reading it file by file.

5. Sentry MCP

The Sentry MCP server lets an agent search errors, analyze performance, triage issues and read Sentry documentation. The source is MIT-licensed. The hosted endpoint at mcp.sentry.dev/mcp uses OAuth for every connection, and its URL can be scoped to one organization and project. When scoped, Sentry says “tools automatically default to the constrained org/project and unnecessary discovery tools are hidden,” which trims both context and reach.

Teams on self-hosted Sentry run the server over stdio with a --host flag. That path needs a user token with scopes that include project:write, team:write and event:write, broader than a triage task needs. Tool exposure can be narrowed with MCP_SKILLS and MCP_DISABLE_SKILLS. Sentry’s AI agent, Seer, is left out of the default skills on self-hosted installs because it “is not part of self-hosted Sentry.”

Limits: in the self-run version, the natural-language search tools (search_errors, search_issues and others) need a separate LLM provider key, and are unavailable without one. Stack traces and event payloads can contain user data, which then enters the model’s context. Best fit: fixing a production bug from the issue, with the actual trace in front of the agent.

6. Serena

Serena, from Oraios, gives an agent “semantic code retrieval, editing, refactoring and debugging tools” at the symbol level. It sits on language servers, the same machinery IDEs use for go-to-definition, and supports more than 40 languages. Tools include find symbol, find referencing symbols, rename, move, safe delete, and replace a symbol’s body. A paid JetBrains plugin backend adds interactive debugging.

The case for Serena is efficiency on large codebases. Instead of grepping and reading whole files, the agent asks for one symbol and its references. The project quotes agents describing how operations “that would cost 8 to 12 careful steps collapse into one atomic call.” That is a qualitative claim from the project, not a measured benchmark. Installation is uv tool install -p 3.13 serena-agent followed by serena init.

Limits: the licence is mixed. The language-server layer is MIT, but the application is GPL-3.0-or-later, and “distributions combining both fall under GPL,” which matters to anyone embedding it. Serena also ships file and shell tools that overlap with the agent’s own, so it widens the agent’s local permissions rather than narrowing them. Best fit: large, typed codebases where cross-file refactors are common.

Databases and issue tracking

Database and ticket servers are where agents start making changes that outlive the session. Both vendors here publish read-only modes. The ranking assumes they are used.

7. Supabase MCP

The Supabase MCP server is Apache 2.0 and hosted at mcp.supabase.com/mcp, with dynamic client registration so most users never create a token by hand. A local version runs with the Supabase CLI at localhost:54321/mcp, though the repository notes it offers “a limited subset of tools and no OAuth 2.1.”

Supabase’s documentation is the most direct of any vendor here about risk, and its controls are URL parameters:

• read_only=true makes the server “execute all queries as a read-only Postgres user.”
• project_ref=<id> restricts it to one project, “disabling account tools.”
• features=database,docs enables only the listed tool groups.

The same page describes the prompt-injection case concretely: a customer writes instructions into a support ticket stored in the database, and an agent reading that row acts on them with the developer’s permissions. Its advice is to “connect to a production project only when the task requires production evidence,” keep manual approval on for each tool call, and never give MCP access to end users.

Limits: all default feature groups are on unless restricted, and SQL execution against a writable role is one injected row away from data loss. Best fit: teams on Supabase working against development projects or branches. Teams on other Postgres hosts will find comparable servers from their provider.

8. Linear MCP

Linear’s MCP server is a hosted service at mcp.linear.app/mcp using Streamable HTTP, with SSE kept as a deprecated fallback. Authentication is OAuth 2.1 with dynamic client registration by default, with API keys and bearer tokens as alternatives. Linear lists Claude, Cursor, VS Code, Windsurf, Zed and Codex among supported clients.

Its tools cover “finding, creating, and updating objects in Linear like issues, projects, and comments.” For a coding agent, that means reading acceptance criteria before writing code and updating the ticket when the work lands.

Limits: “Read-write access is provided through https://mcp.linear.app/mcp by default.” A separate /mcp/readonly endpoint exists, and it is the sensible default for an agent that only needs to read requirements. Ticket text written by anyone in the workspace, or synced in from support tools, is untrusted input. Using several workspaces requires separate configuration. The server is closed-source. Best fit: teams already on Linear that want issue context inside the agent without copy and paste.

Design and infrastructure

The last two servers matter to narrower groups: front-end teams that build from Figma files, and platform teams that manage infrastructure as code.

9. Figma MCP server

The Figma MCP server lets an agent “select a Figma frame and turn it into code,” pulling layout, variables and components through tools such as get_design_context, get_variable_defs, get_screenshot and get_metadata. Code Connect maps Figma components to the team’s real components, so generated code reuses them instead of reinventing them. The Help Center guide names the hosted endpoint at mcp.figma.com/mcp as preferred. A desktop server running inside the Figma app requires a Dev or Full seat on a paid plan.

Newer write-to-canvas tools create frames, components, variables and auto layout in Figma itself. They are in beta, “available for free during the beta period,” and will later become paid.

Limits: cost and access are seat-bound. Figma’s rate-limit table gives View and Collab seats between 6 and 20 read calls a month, depending on plan, against 200 to 600 a day for Dev and Full seats. Only clients listed in Figma’s MCP catalog can connect. Best fit: design-system teams with Code Connect set up and Dev seats for the engineers who use it.

10. Terraform MCP Server

HashiCorp’s Terraform MCP Server, under MPL-2.0, connects an agent to the public Terraform Registry for provider and module documentation, and to HCP Terraform or Terraform Enterprise for workspaces, projects and private registries. It runs over stdio by default or Streamable HTTP for shared deployments, authenticating with a TFE_TOKEN.

Its tool surface is organized into toolsets (registry, registry-private, terraform) with a filtered default. For coding agents, the registry tools solve the same problem Context7 solves for libraries: provider arguments change between versions, and models get them wrong.

The more consequential tools are gated. An ENABLE_TF_OPERATIONS flag controls whether “tools that require explicit approval” are available, so runs that change infrastructure are off unless an operator turns them on.

Limits: HashiCorp warns that the server “may expose certain Terraform data to the MCP client and LLM” and says not to use it “with untrusted MCP clients or LLMs.” Workspace variables and state outputs can include secrets. Best fit: infrastructure teams writing HCL who want current provider documentation, with workspace operations left disabled until there is a review step.

Tool definitions and the context budget

Every tool a server exposes comes with a name, a description and a JSON schema for its inputs. In clients that send all of them to the model on each turn, ten servers can occupy a meaningful share of the context window before the agent reads a line of code. That pushes up input tokens and makes tool choice harder for the model. It is the same per-turn cost dynamic described in the piece on reasoning-model inference costs.

Clients handle this differently, and the differences are documented:

Claude Code’s documentation and the Codex documentation give the most direct controls. Outside those two, the server-side switches matter more: GitHub’s toolsets, Sentry’s org and project scoping, Supabase’s feature groups, Chrome DevTools’ slim mode and Terraform’s toolsets all shrink the catalog at the source. A small catalog has a second benefit. A tool the agent cannot see is a tool an injected instruction cannot call.

Risks of MCP servers on developer laptops

The servers in this list are maintained by credible teams. The risk sits less in any single one of them than in how MCP servers accumulate on developer machines: added one at a time, configured per client, holding tokens nobody inventories. Three patterns stand out.

Credential sprawl. Each server needs a credential, and many end up as long-lived tokens in plain JSON or TOML files: ~/.claude.json, .cursor/mcp.json, ~/.codex/config.toml, mcp_config.json. A developer using four clients may hold four copies of the same GitHub token. The specification’s Security Best Practices warn that broad scopes produce an “expanded blast radius” when a token leaks. OAuth-based remote servers (GitHub, Sentry, Supabase, Linear, Figma) reduce the problem, because they avoid hand-copied tokens. Claude Code also reads credential variables such as ANTHROPIC_API_KEY as empty in remote server URLs and headers, which prevents a class of leaks.

Prompt injection through tool results. Any tool that returns text written by someone else (an issue, a web page, a database row, a ticket, a documentation snippet) can carry instructions. In May 2025 Invariant Labs showed a malicious public GitHub issue steering an agent into reading private repositories and leaking data from them, including salary information in the proof of concept. Simon Willison’s lethal trifecta names the conditions: “access to your private data,” “exposure to untrusted content,” and “the ability to externally communicate.” A coding agent with GitHub, a browser and a database server connected has all three. Read-only modes, narrow scopes and approval prompts on write tools break the chain at different points.

Unvetted servers. The specification describes local servers as binaries that “may have direct access to the user’s system,” and lists malicious startup commands and payloads among the attacks. This is not theoretical. In September 2025 an npm package called postmark-mcp, imitating a legitimate integration, added one line in version 1.0.16 that BCC’d every email it sent to an outside address. The official MCP Registry verifies namespace ownership through GitHub or DNS, which helps against impersonation, but it is still in preview and documents no security review of the code it lists.

Client-side controls help one machine at a time. Claude Code asks for approval before using project-scoped servers from a repository’s .mcp.json in interactive sessions, though not under claude -p or the SDK, and supports managed allow and deny lists. VS Code shows a trust dialog before starting a server and offers sandboxing on macOS and Linux. Devin Desktop lets team admins allowlist servers, after which “all non-allowlisted servers will be blocked.” Cursor asks for approval before tool use by default.

What none of these provides is a fleet-wide view across clients. Two layers address that. An MCP gateway puts shared servers behind one endpoint with per-user tool access and logging. The Bifrost MCP gateway, part of the Apache 2.0 Go project from Maxim AI, denies MCP tools by default to any virtual key that has not been granted them. Its code mode replaces large tool catalogs with four meta-tools; Bifrost reports input-token reductions of 58.2 percent at 96 tools and 92.8 percent at 508 tools, from its own benchmark. The other layer sits on the device. Bifrost Edge, currently in alpha, reads the MCP configuration of supported apps (Claude Code, Claude Desktop, Gemini CLI, OpenCode, Codex and Cursor), builds a fleet inventory, sends newly found servers to an approval queue and enforces deny decisions on each machine. Edge routes traffic through the gateway, so guardrails configured there, such as Gitleaks-backed secrets detection and checks on content returned from tools, also apply to coding agents. Guardrails are an enterprise-tier gateway feature, and an alpha product is something to pilot, not a finished control. The wider field of gateways is compared in the MCP gateway guide.

A starting configuration by workflow

Most developers do not need all ten servers. The table below maps common workflows to a minimal set, with the safest mode to start in.

Two habits matter more than the selection. Add servers at the narrowest scope the client offers: a project-scoped entry in Claude Code or .cursor/mcp.json rather than a global one. And give each server the narrowest token it can work with, which for GitHub means a fine-grained token limited to the repositories in question.

Limits of this comparison

This ranking is built from documentation, READMEs, licence files and security pages read in early October 2026. No server was installed, load-tested or penetration-tested for this piece, and no tool-definition token counts were measured. Tool counts are the maintainers’ own and change between releases. The ranking reflects a general developer workflow on GitHub. A team on GitLab, Jira or Vercel, or one whose work is mostly infrastructure, would order the list differently.

Several capable servers were left out by design: Docker’s MCP tooling (covered as a gateway), the reference Git and filesystem servers (duplicating built-in agent tools), and platform servers from Cloudflare, Vercel, AWS and Neon (useful only on those platforms). Pricing beyond what vendors publish on their documentation pages was not compared. Nothing here substitutes for reading a server’s source before giving it a token. For the model-side half of the agent loop, the guide to running an AI gateway in front of every model call covers routing, budgets and logging.