I Tested 8 MCP Servers So You Don't Have To
A hands-on evaluation of the most popular MCP servers for Claude Code. Most failed. Three didn't.
I spent last weekend connecting every MCP server I could find to Claude Code. The promise was compelling: give your AI agent access to your filesystem, GitHub, databases, and APIs. Let it write code and execute it. Let it browse documentation and update your docs.
I tested eight. Three made the cut. Five ranged from “unreliable” to “actively dangerous.” Here’s what worked, what didn’t, and the criteria I’d use if I were onboarding a team tomorrow.
The winners
1. Filesystem MCP (Local scope)
The simplest and most reliable. It gives Claude Code read/write access to a specific directory you define. Nothing else.
Why it works: It’s bounded. You point it at /home/user/projects/myapp and that’s all it can touch. It can’t wander into your SSH keys or system files. The failure mode is predictable: try to write outside the scope, get a permission error.
Production verdict: Use it. But scope it narrowly. Don’t point it at your entire home directory because it’s convenient.
2. GitHub MCP (Read-only first)
The GitHub MCP server lets Claude read repos, create issues, and open pull requests. The write capabilities are genuinely useful—I’ve had Claude draft PR descriptions and create tracking issues—but I run it in read-only mode by default.
Why read-only wins: An agent with write access to your repo can push broken code at 3 AM. It can create issues with titles like “Fix the thing” and no description. The blast radius is large enough that I want a human checkpoint.
My workflow: Read-only for research and context gathering. Escalate to write access for specific, scoped tasks, then revoke.
3. Fetch MCP (With domain safelist)
This one surprised me. It’s a simple web fetch tool, but configured correctly, it’s the gateway to everything else. Documentation lookups. API reference checks. Status page monitoring.
The key: Domain restrictions. The default configuration lets it hit any URL. That’s fine for personal use, but in a team environment, I restrict it to known documentation domains: docs.python.org, platform.openai.com, your internal wiki.
Why it matters: Without restrictions, an agent can be tricked into fetching malicious content. With them, it’s a bounded research tool.
The failures
4. PostgreSQL MCP (Full write access)
I wanted this one to work. The demo is compelling: “Show me all users who signed up last week” and Claude queries your production database and returns a formatted answer.
The problem: Production databases are not chatbot playgrounds. I watched Claude attempt to run a SELECT * on a table with 2M rows because I asked for “all recent data.” It would have worked—eventually—but the performance impact would have been real.
What I’d need to use it: Read-only credentials, query timeouts, and explicit row limits in the tool configuration. None of which are defaults.
5. Stripe MCP
Connecting your AI agent to your payment processor feels like a bad idea, and it is.
The Stripe MCP server can create charges, refund customers, and update subscriptions. These are high-stakes operations with financial and legal implications. The error modes aren’t technical—they’re “explain to your CFO why we refunded $50,000 to the wrong customer.”
Verdict: Don’t. If you need Stripe data in your workflow, export it to a reporting database and give the agent read access to that.
6. Generic API MCP (Open-ended)
There’s a category of MCP servers that claim to connect to “any API.” You provide an OpenAPI spec and they generate tools dynamically.
In practice, this means your agent can call any endpoint with any parameters. It’s powerful and completely unbounded. I watched Claude attempt to DELETE a resource because my prompt was ambiguous about whether I wanted to “remove” something from a list or delete it permanently.
The lesson: APIs with side effects need human review. Generic API tools skip that review by default.
7. Browser MCP (Unrestricted)
Browser automation is the sci-fi feature everyone wants: “Go check if the competitor changed their pricing and tell me.”
The reality is messier. Unrestricted browser access means your agent can click any link, fill any form, and download any file. In my testing, it got distracted by cookie banners, Terms of Service links, and newsletter popups. It spent 10 minutes trying to close a modal before I killed the session.
Safer approach: Restrict to specific URLs and specific actions (read-only, no form submission).
8. Slack MCP (DMs + channels)
The Slack MCP server can read messages and post to channels. The access model is all-or-nothing: either it can see everything or nothing.
The concern: Most engineering Slacks contain sensitive information. Incident discussions, architecture debates, personnel matters. Giving an agent blanket access means trusting it not to accidentally surface something in the wrong context.
What I’d want: Channel-specific grants, read-only for most channels, and explicit approval for posting.
My production criteria
If I were rolling this out to a team, I’d require four things:
-
Bounded scope: The tool can only touch specific files, directories, or API endpoints. “Access to everything” is a red flag.
-
Read-first defaults: Write access is opt-in, not opt-out. Every write operation should feel like a deliberate choice.
-
Observable behavior: I can see what the agent did, when, and with what tools. Logging isn’t optional.
-
Fast revocation: If something goes wrong, I can disable a tool in under 60 seconds. No digging through config files.
The deeper lesson
MCP servers are powerful because they’re unopinionated. They give your agent the same capabilities you’d have with a terminal and API keys. That’s also why they’re dangerous.
The teams that succeed with MCP won’t be the ones that connect the most tools. They’ll be the ones that connect the fewest tools necessary, with the tightest scopes, and the clearest escalation paths.
Start with Filesystem and GitHub (read-only). Add Fetch with a safelist. Only escalate to write access when you’ve seen the agent behave correctly for days or weeks. And never, under any circumstances, let it touch your payment processor.
Related: