The MCP servers that actually earn their keep with Claude Code

Every week a new “50 best MCP servers” ranking makes the rounds. I installed a good dozen following those lists. One month of client work later, three remain. The others were removed for the same reason: they cost more context than they returned in service.

Here are the three survivors, why they stayed, and the method to evaluate any MCP server in ten minutes before inflicting it on your config.

The hidden cost of an MCP server

First, the criterion the rankings ignore: every MCP server injects its tool definitions into Claude Code’s context, every session. A server with twenty tools is several thousand tokens consumed before your first prompt. Three servers like that, and you have amputated a meaningful share of your context window for tools you might not use all session.

So the question is never “is this server useful?” but “does this server return more than it costs?”. That filter eliminated most of my initial dozen.

1. Playwright: Claude’s eyes on your frontend

The problem it solves: without it, Claude Code edits your CSS, tells you “fixed”, and you discover it is not. With it, Claude drives a real browser, takes screenshots, reads the console, and verifies its own work.

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

The moment it paid for itself: a display regression on a payment form that Claude caught on its own, screenshot attached, before I had reread the code. The “edit, verify, fix” loop runs without me.

Worth knowing: it is the most token-hungry of the three (many tools). I enable it per project, in the .mcp.json of frontend projects only, never in my global user config.

2. Context7: the end of invented API signatures

The problem it solves: Claude knows libraries as they existed at its training date. On a fast-moving lib, it invents plausible but wrong options. Context7 gives it access to current, versioned documentation at the moment it needs it.

{
  "mcpServers": {
    "context7": {
      "command": "npx",
      "args": ["-y", "@upstash/context7-mcp"]
    }
  }
}

The moment it paid for itself: an Astro migration where Claude was using the previous version’s API. With Context7 it checked the docs for the installed version and corrected its own code without a single error round-trip.

Worth knowing: only two tools, minimal context cost. It is the only one of the three I keep in my global user config.

3. GitHub: useful, but not for what you think

The problem it solves: reading issues, reviewing PRs, searching across repos, without leaving the session. For a freelancer juggling several client repos, it is the thread that ties everything together.

{
  "mcpServers": {
    "github": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-github"],
      "env": {
        "GITHUB_PERSONAL_ACCESS_TOKEN": "${GITHUB_MCP_TOKEN}"
      }
    }
  }
}

The honest nuance the listicles never make: if you have the gh CLI installed, Claude Code already knows how to use it through Bash, no MCP server involved. For creating a PR or reading an issue now and then, gh is enough and costs zero tokens in tool definitions. The MCP server only earns its place if your workflow genuinely centers on GitHub: issue triage, review batches, multi-repo search.

Note the ${GITHUB_MCP_TOKEN} reference: the token lives in your environment, never in the versioned file. If you share that .mcp.json with a team, I covered the rules in sharing a Claude Code config across a team.

The ones I removed, and why

• The database server for daily use: too many tools for my actual need, which was “run this query occasionally”. psql through Bash does the same job. I re-enable it selectively for big schema-exploration sessions.
• SaaS service servers (project management, notes, calendar): the integration was real but the need came once a week. A browser tab costs less than a permanent set of tool definitions.
• Any unmaintained server: an MCP server that has not been updated in six months breaks silently after a Claude Code update or a change in the API it wraps. Check the last commit date before installing.

Evaluating any MCP server in ten minutes

1. Count its tools. More than ten tools for your single use case is a bad context-to-service ratio.
2. Look for the CLI equivalent. If a binary Claude already knows how to drive does the job (gh, psql, curl), the server has to offer more than convenience.
3. Test on a real task, not the README demo. The demo is optimized, your case is not.
4. Look at what it asks for. A server that wants a broad token when your need is read-only deserves a restricted token, or a refusal.
5. Decide where it lives: user config (every session pays for it) or project .mcp.json (only the relevant project pays). When in doubt, project.

The rule of three

My stable config: Context7 globally, Playwright and GitHub per project, as needed. Three active servers maximum in any given session. Every addition beyond that has to push another one out.

It is not a technical limit, Claude Code accepts far more. It is budget discipline: the context your MCP servers do not consume is context available for your code. And if you want to check what your context window actually holds, I wrote about how to measure it.