Why MCP Servers Matter
By itself, Claude Code has access to your local file system and shell. It can read your codebase, run build commands, and commit changes. But it operates blind to the systems where code actually ships. Without MCP servers, Claude Code cannot:
- Query your GitHub issues, pull requests, or merge conflicts
- Read or write data in your database
- Check error logs in Sentry or other observability tools
- Run end-to-end tests in a browser
- Access documentation for libraries at their specific versions
MCP (Model Context Protocol) bridges this gap. An MCP server exposes a set of tools—resources and functions—that Claude Code can call. Instead of manually switching context between tools, Claude stays in one session and coordinates across your entire stack: GitHub, databases, APIs, browsers, monitoring dashboards.
Before You Start
Prerequisites:
- Claude Code installed and working (check with
claude --version) - Node.js 18 or newer for servers started with
npx - Read access to the services you want to connect (GitHub token, database connection string, API key)
- A clear idea of your workflow: which tools you use daily, and where Claude Code currently can't help
Context cost in 2026: Claude Code now runs MCP tool search by default. At session start only tool names and server instructions load; full tool definitions load when Claude actually needs them. Servers no longer flood your context just by being installed. Full definitions still load upfront if you set ENABLE_TOOL_SEARCH=false, route Claude Code through a non-first-party ANTHROPIC_BASE_URL proxy, or mark a server alwaysLoad: true. Tool results still cost tokens: Claude Code warns when one MCP tool output passes 10,000 tokens and caps it at 25,000 by default (MAX_MCP_OUTPUT_TOKENS).
So the reason to keep your server list short is no longer mainly startup tokens. It's tool overlap, credentials and maintenance: every server is code or a service acting with your access.
Five Criteria for Evaluation
Not all MCP servers are equally useful or safe. Check these five things before adding one.
1. Maintenance and reliability
What to check: recent commits and tagged releases, responses to issues, a named maintainer.
- Prefer vendor-maintained servers (GitHub, Notion, Sentry, Figma, Microsoft's Playwright) where they exist
- Use the official MCP Registry to find servers and their publishers, then check the source repository yourself
- Skip servers with no releases or unresponsive maintainers
2. Security and permission scope
What to check: does the server ask only for the access it needs? Can it run read-only?
- A Slack server shouldn't need your filesystem; a CRM server shouldn't need broad network access
- Use the narrowest credentials possible: a fine-grained GitHub token, a read-only database user, a scoped API key
- Be careful with database servers: read-only access is low-risk, write access is only for cases where you trust the workflow and have backups
3. Fit to your workflow
What to check: does it unlock a task you do every week, or is it a novelty?
- High impact: tools your team uses daily, such as GitHub (if you work in PRs), your database, Context7 for library docs
- Medium impact: tools for specific phases, such as Playwright for UI verification, Sentry for production errors, Linear for issues
- Low impact: niche servers you'd use once a month
4. Documentation and setup friction
What to check: clear install steps, working examples, documented troubleshooting.
- Official servers usually document remote URLs, auth and permissions well
- Community servers vary; read the whole README before installing
5. Compatibility
What to check: remote (HTTP) or local (stdio/Docker)? Does it work with your client?
- MCP is an open standard; the same server usually works in Claude Code, Claude Desktop, Cursor and other MCP clients
- Prefer HTTP for remote servers; SSE is deprecated
- Old servers may not support recent protocol changes; check when the server was last updated
Step-by-Step Selection Process
Step 1: Audit your workflow
List the tools you use and the gaps Claude Code can't fill:
Tools we use daily:
- GitHub (PRs, issues, code review)
- PostgreSQL (schema, queries, test data)
- Slack (team communication, approvals)
- Figma (design reference)
- Sentry (production errors)
Gaps Claude Code cannot fill:
- Search GitHub issues or create PRs
- Query our database
- Send status updates to Slack
- Read design files
- Check production errorsCircle the 2–3 gaps where a server would save the most time each week.
Step 2: Start with the foundational servers
For most developers that means three:
- GitHub (official, by GitHub): high impact if you work with pull requests
- Context7 (by Upstash): version-specific library docs, less reliance on stale training data
- Playwright (by Microsoft): lets Claude verify its own UI changes in a real browser
You don't need a Filesystem server (Claude Code already reads and edits local files) or a Sequential Thinking server (current Claude models reason step by step natively). Start with 1–2 and add more only for a specific need.
Step 3: Research candidates
For each server, spend 10 minutes on due diligence:
Server name: [ ]
Vendor or maintainer: [ Vendor | Active community | Inactive ]
Latest release date: [ ]
Open issues answered? [ Yes | Slowly | No ]
Remote or local: [ HTTP | stdio | Docker ]
Auth: [ OAuth | Token | None ]
Read-only mode available? [ Yes | No | Partial ]
Fit to your workflow: [ High | Medium | Low ]
Decision: [ Install | Skip | Revisit later ]Find candidates on the official MCP Registry or in vendor docs, then read the source repository.
Step 4: Test locally
Install the server for yourself first (default local scope):
claude mcp add --transport http github https://api.githubcopilot.com/mcp/ \
--header "Authorization: Bearer YOUR_GITHUB_PAT"claude mcp listIf it fails, claude mcp get github shows the error.
Step 5: Audit the tools it exposes
In a session, open /mcp, select the server and review its tools. Confirm that:
- The tool list matches what the server claims to do
- You understand what each tool can change
- Write tools are disabled if you need read-only (the GitHub server, for example, has a read-only mode)
Step 6: Run a real task
Use the server for a real but low-stakes task: review an actual pull request, run a real read-only query. This shows integration gaps before you rely on it.
Step 7: Share and monitor
When it works, add it at project scope so the team gets the same setup:
claude mcp add --scope project playwright -- npx @playwright/mcp@latestThis writes .mcp.json at the project root:
{
"mcpServers": {
"playwright": {
"type": "stdio",
"command": "npx",
"args": ["@playwright/mcp@latest"]
}
}
}JSON has no comments, so record why each server is there in your README or CLAUDE.md. Keep tokens out of the committed file. Review MCP config changes like code, and watch Claude's tool calls in early sessions; if a server returns more data than expected, restrict its scope or remove it.
Common Pitfalls and How to Avoid Them
Pitfall 1: Installing everything at once
Tool search keeps idle servers cheap, but a long list of overlapping tools makes Claude's tool choice less reliable and multiplies the credentials you're exposing. Start with 1–2 high-impact servers and add more for specific needs.
Pitfall 2: Write credentials when read-only would do
If a database server has full write access and a tool call goes wrong, you can lose data. Use read-only credentials unless you explicitly need changes.
Pitfall 3: Unmaintained or unvetted servers
A server with no recent releases and an unknown publisher is a liability: no fixes, and unknown security exposure. Stick to vendor-maintained servers or active community projects with clear provenance.
Pitfall 4: Skipping the test phase
Try a new server on a task that doesn't matter first. You'll catch authentication issues, permission bugs and unexpected tool behaviour before they cause damage.
Pitfall 5: Forgetting credential rotation
If a server is compromised, the damage is limited only by the permissions you gave it. Rotate tokens regularly and use scoped access (fine-grained GitHub tokens, database read-only roles).
Frequently Asked Questions
Can I use the same MCP server in Claude Code, Cursor and other tools?
Yes. MCP is an open standard, so the same server usually works across compatible clients. Write the integration once, use it everywhere.
What if a server breaks my workflow?
Remove it with claude mcp remove <server-name>; your sessions continue without it. File an issue with the maintainer or switch to an alternative. You're not locked in.
Is there a public registry of servers?
Yes: the official MCP Registry, run by the MCP project, lists servers and their publishers. Vendors also document their own official servers, and Anthropic's Claude Marketplace lists connectors and plugins. A registry listing isn't a security audit: still read the source before you install.
Do MCP servers cost money?
The protocol and most open-source servers are free. Vendor servers (GitHub, Notion, Sentry, Supabase) are free to connect, but the underlying service has its own pricing. Some servers, such as Context7, offer free API keys with rate limits.