# MCP servers worth connecting to a coding agent

> The servers that do real work in a Claude Code or Cursor setup — repositories, databases, browsers, files, and the project backlog — with what each one exposes.

Source: https://autoplans.dev/guides/mcp-servers-for-developers

Most lists of MCP servers are catalogues: everything anyone has published,
sorted by star count. This is not that. It is the short set a working developer
connects to a coding agent and keeps connected, grouped by what each one
touches — the repository, the database, a browser, the filesystem,
documentation, and the project backlog. For each server: what it exposes, which
transport it speaks, where its configuration lives, and the one thing that goes
wrong.

Two rules shaped the selection. Every server here was opened on its own
repository on the review date; nothing is included on reputation alone. And
"best MCP servers for developers" is read narrowly, as MCP servers for coding
agents rather than for chat: a server earns its place by doing something the
agent cannot already do with a shell and an editor. An agent that can run `git`
gains nothing from a git wrapper; a chat client with no shell gains a great
deal.

## Where the configuration lives

Every server below is declared as a JSON block. The block is nearly the same
everywhere; the file it goes in is not.

| Client | File | Notes |
|---|---|---|
| Claude Code | `.mcp.json` in the project root (shared), or `~/.claude.json` for the local and user scopes | `claude mcp add --transport http\|stdio` writes it for you |
| Cursor | `.cursor/mcp.json` in the project, `~/.cursor/mcp.json` for every project | Remote servers take `url` and `headers`; local ones `command`, `args`, `env` |
| VS Code with Copilot | `.vscode/mcp.json` | The top-level key is `servers`, not `mcpServers`; an `inputs` array of `promptString` entries keeps secrets out of the file |
| Claude Desktop | `claude_desktop_config.json`, opened from Settings → Developer → Edit Config | Launches stdio servers with `command` and `args` under `mcpServers` |

The specification defines two transports: stdio, where the client launches the
server as a subprocess, and Streamable HTTP, where the server is a process the
client reaches over HTTP POST. The older HTTP+SSE transport is deprecated —
Claude Code's documentation still accepts `--transport sse` but tells you to use
HTTP where available. Prefer HTTP for anything hosted, and stdio for anything
that needs to see your local disk or browser.

## Source control

### The GitHub MCP server

Repository: [github/github-mcp-server](https://github.com/github/github-mcp-server).
GitHub MCP is organised as toolsets — `context`, `repos`, `issues`,
`pull_requests`, `actions`, `code_security`, `discussions`, `notifications`,
`projects` and about two dozen in all — of which `context`, `repos`, `issues`,
`pull_requests` and `users` are enabled when you name none.

Transport: Streamable HTTP at `https://api.githubcopilot.com/mcp/`, hosted by
GitHub and authenticated with OAuth or a personal access token; or stdio through
the `ghcr.io/github/github-mcp-server` Docker image with
`GITHUB_PERSONAL_ACCESS_TOKEN` in the environment.

```bash
claude mcp add --transport http github https://api.githubcopilot.com/mcp/
```

Caveat: toolsets multiply. Every one you enable adds its tools to every model
call. Keep to the defaults, pass `--toolsets` (or `GITHUB_TOOLSETS`, which takes
precedence) with only what the session needs, and use `--read-only` — or
`GITHUB_READ_ONLY=1` in Docker — when the agent is meant to read issues rather
than merge pull requests.

### The git reference server

Repository: [modelcontextprotocol/servers](https://github.com/modelcontextprotocol/servers),
directory `src/git`. Run with `uvx mcp-server-git --repository path/to/repo`, it
exposes twelve operations: `git_status`, `git_diff`, `git_diff_staged`,
`git_diff_unstaged`, `git_log`, `git_show`, `git_add`, `git_reset`,
`git_commit`, `git_branch`, `git_create_branch` and `git_checkout`.

Transport: stdio.

Caveat: Claude Code, Cursor and Copilot already run `git` in a shell. This
server is for clients without one — Claude Desktop is the usual case — and is
redundant everywhere else.

## Databases

### Postgres MCP Pro

Repository: [crystaldba/postgres-mcp](https://github.com/crystaldba/postgres-mcp).
The reference PostgreSQL server has been moved out of the main servers
repository into the archived collection, so this is the maintained option for
Postgres MCP work. Its tools cover the schema (`list_schemas`, `list_objects`,
`get_object_details`), queries (`execute_sql`, `explain_query`), and health and
index analysis (`analyze_db_health`, `analyze_workload_indexes`,
`analyze_query_indexes`, `get_top_queries`).

Transport: stdio by default, `--transport=sse` for the deprecated SSE form.
Installed with `pipx install postgres-mcp`, `uv pip install postgres-mcp`, or
the `crystaldba/postgres-mcp` Docker image; the connection comes from
`DATABASE_URI`.

```json
{
  "mcpServers": {
    "postgres": {
      "command": "postgres-mcp",
      "args": ["--access-mode=restricted"],
      "env": { "DATABASE_URI": "postgresql://user:password@localhost:5432/app" }
    }
  }
}
```

Caveat: `--access-mode=restricted` is the read-only mode, with execution-time
limits, that the project intends for production; `unrestricted` can alter schema
and data. The connection string is a credential, so it belongs in `env`, and the
role it names should be one you would hand to a contractor.

## Browsers

### Playwright MCP

Repository: [microsoft/playwright-mcp](https://github.com/microsoft/playwright-mcp),
package `@playwright/mcp`. Playwright MCP drives a real browser through
structured accessibility snapshots rather than screenshots, which is why it
works with a model that has no vision: `browser_navigate`, `browser_snapshot`,
`browser_click`, `browser_type`, `browser_evaluate`, `browser_wait_for` and
their siblings. Chromium, headed, by default; `--headless` and
`--browser firefox|webkit|msedge|chrome` change that, and `--caps` adds the
optional vision, pdf, devtools, network, storage and testing tools.

Transport: stdio through `npx @playwright/mcp@latest`; `--port 8931` runs it as
a standalone HTTP server that clients reach at `http://localhost:8931/mcp`.

```bash
claude mcp add playwright npx @playwright/mcp@latest
```

Caveat: the default profile is persistent, so a session that logged in to
something stays logged in for the next one. `--isolated` keeps the profile in
memory and discards it when the browser closes.

### Chrome DevTools MCP

Repository: [ChromeDevTools/chrome-devtools-mcp](https://github.com/ChromeDevTools/chrome-devtools-mcp),
run with `npx -y chrome-devtools-mcp@latest`. Where Playwright MCP is for
driving pages, this one is for diagnosing them: performance traces, network
requests, console messages with source-mapped stack traces, screenshots, and
`--browser-url=http://127.0.0.1:9222` to attach to a Chrome that is already
running.

Transport: stdio.

Caveat: the project's own warning is the caveat. It exposes the contents of the
browser instance to the client, which can inspect, debug and modify anything in
it. Attach it to a profile that is not logged in to anything you would mind the
model reading.

## Files

### The filesystem MCP server

Repository: [modelcontextprotocol/servers](https://github.com/modelcontextprotocol/servers),
directory `src/filesystem`, package `@modelcontextprotocol/server-filesystem`.
Thirteen tools: `read_text_file`, `read_media_file`, `read_multiple_files`,
`write_file`, `edit_file`, `create_directory`, `list_directory`,
`list_directory_with_sizes`, `directory_tree`, `search_files`, `move_file`,
`get_file_info` and `list_allowed_directories`.

Transport: stdio.

```json
{
  "mcpServers": {
    "filesystem": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-filesystem", "/home/you/projects"]
    }
  }
}
```

Caveat: this is the canonical Claude Desktop server and is redundant in a coding
agent, which reads and edits files natively. Allowed directories come from the
command arguments, or from MCP roots, which replace the argument list entirely
when the client sends them; a server started with neither fails to initialise.
It runs with your user's permissions, so that list is the whole security model.

## Search and documentation

### Context7

Repository: [upstash/context7](https://github.com/upstash/context7). Two tools:
`resolve-library-id` turns a library name into a Context7 id, and `query-docs`
returns current documentation for that id. It answers the thing a model with a
training cutoff cannot — what the API looks like today.

Transport: HTTP at `https://mcp.context7.com/mcp`, with an optional
`Authorization: Bearer` key for higher rate limits; or stdio through the
`@upstash/context7-mcp` package.

Caveat: the agent has to call `resolve-library-id` first and pick the right
library among near-duplicates. When an answer looks wrong, check which id it
chose.

### The fetch server

Repository: [modelcontextprotocol/servers](https://github.com/modelcontextprotocol/servers),
directory `src/fetch`, run with `uvx mcp-server-fetch`. One tool, `fetch`, that
retrieves a URL and converts it to Markdown, with `max_length` (5,000 characters
by default), `start_index` for paging through a long page, and `raw`.

Transport: stdio.

Caveat: it obeys `robots.txt` for requests the model initiates but not for ones
you initiate, unless started with `--ignore-robots-txt`. Its own README notes it
can reach local and internal IP addresses, so a page the agent is told to fetch
can point it at something on your network.

### Brave Search

Repository: [brave/brave-search-mcp-server](https://github.com/brave/brave-search-mcp-server),
package `@brave/brave-search-mcp-server`. Eight tools — `brave_web_search`,
`brave_local_search`, `brave_news_search`, `brave_image_search`,
`brave_video_search`, `brave_place_search`, `brave_summarizer` and
`brave_llm_context` — behind a `BRAVE_API_KEY`.

Transport: stdio by default; `--transport http` with `--port` serves HTTP.

Caveat: eight tools for what is usually one capability. If the agent only ever
needs `brave_web_search`, the rest are schema overhead on every call — which is
why the server ships `--enabled-tools` and `--disabled-tools`.

## The project backlog

### Autoplans

An MCP server for project management is the entry most lists leave out, because
a coding agent never asks for one. It asks for a plan, the plan arrives as a
prompt, and it is gone when the session ends. Autoplans exposes projects and
tasks as MCP tools so a session reads what it is meant to build from the backlog
instead.

Transport: Streamable HTTP at `https://autoplans.dev/api/v1/mcp`, authenticated
with an API key as a bearer token. Clients limited to stdio use the
`autoplans-mcp` npm package, which bridges to the same endpoint.

```json
{
  "mcpServers": {
    "autoplans": {
      "type": "http",
      "url": "https://autoplans.dev/api/v1/mcp",
      "headers": { "Authorization": "Bearer apk_live_..." }
    }
  }
}
```

What it exposes: around forty tools across projects, tasks, subtasks, comments,
assignment, branding, business plans, telemetry, and a code-agent group shaped
for working a backlog. `list_tasks` returns every task with `parentTaskId`,
`dependsOnTaskIds`, `subtaskCount` and `commentCount`, so one call carries the
whole graph; `code_agent_get_task_with_dependencies` answers whether a task can
be started yet. The full list is in [MCP tools](/docs/tools) and the per-client
blocks are on the [MCP server page](/mcp-server).

Caveat: forty tools is a lot, and the next section is about exactly that. It is
why the Autoplans desktop app and CLI ship a bundled plugin exposing thirteen
task-shaped tools rather than the whole server, and why the
[Claude Code plugin](/docs/claude-code) connects the same server but adds skills
for planning, starting and finishing work on top of it.

## What tool count costs

Every tool a connected server exposes is a JSON schema attached to every model
call in the session. Add up the counts in this guide — thirteen for the
filesystem server, twelve for git, eight for Brave, around forty for Autoplans —
and you are past seventy before GitHub, Playwright and Chrome DevTools have
contributed theirs. The cost is tokens on every turn, but the failure mode is
worse than the cost: some inference endpoints refuse a large tool payload
outright, and free endpoints have answered `503` to the forty Autoplans tools.
That incident, and the reduction that followed, is written up in
[the MCP tool count 503](/blog/mcp-tool-count-503).

Three habits keep it in check.

- Connect the servers a task needs, not the servers you own. A project-scope
  `.mcp.json` or `.cursor/mcp.json` per repository is the mechanism.
- Use the server's own reduction flag: GitHub's `--toolsets`, Brave's
  `--enabled-tools`, Playwright's `--caps` left off, Postgres MCP Pro's
  restricted access mode.
- Know what your client does with the list. Claude Code's documentation says
  tool search is on by default and loads only tool names and server instructions
  at session start, deferring the full definitions until a tool is needed — and
  that it is disabled under a custom `ANTHROPIC_BASE_URL` or with
  `ENABLE_TOOL_SEARCH=false`. Cursor's and VS Code's documentation describe no
  such deferral, so assume the whole set is sent.

## Questions

### Which are the essential MCP servers for Claude Code?

Fewer than you would think, because Claude Code already has a shell, file tools
and web fetch. The gap is whatever sits behind authentication or outside the
repository: GitHub for issues and pull requests, a database server for the
schema, Playwright for anything with a browser, and a backlog so the plan
outlives the session. Context7 earns a place when the project depends on a
fast-moving library.

### How do I add an MCP server to Cursor?

Create `.cursor/mcp.json` in the project, or `~/.cursor/mcp.json` for every
project, with an `mcpServers` object. A remote server takes `url` and optional
`headers`; a local one takes `command`, `args` and `env`. The entries that work
as MCP servers for Cursor work for Claude Code too; only the file moves. A
worked example is on the
[Cursor MCP server configuration](/mcp-server/cursor) page.

### Do I need a filesystem MCP server with a coding agent?

No. Claude Code, Cursor, Copilot, Windsurf and Cline read and edit files
themselves. That server exists for chat clients that do not, and adding it to a
coding agent gives the model two ways to do the same thing.

### What is an MCP server for project management?

A server that exposes projects and tasks as tools, so the agent can read its
backlog, check what a task depends on, and mark it done without a human relaying
any of it. Autoplans is one. The
[Model Context Protocol guide](/guides/model-context-protocol) covers the
protocol itself, and
[why a coding agent needs a backlog](/guides/ai-coding-agent-backlog) covers the
reasoning.