I connected 5 MCP servers to Claude Code in one afternoon. Two made the cut.

I connected five MCP servers to my Claude Code setup in one afternoon, and only two are still running now: Fetch and Playwright. Filesystem and memory both worked fine when I tested them live; git's numbers come from its own docs, since a Python version block kept me from running it here. I turned all three off anyway.

This is for you if you've read one of the dozen "best MCP servers" roundups and still don't know which ones are actually worth a tool-slot. By the end you'll have the exact tool count for all five and the test that decided which ones survived.

Here's the honest catch: none of the three I dropped ever crashed or threw an error. They just turned out to duplicate work Claude Code already does natively, and that's a harder thing to notice than a server going down.

What I actually wanted to find out

I wanted to know which of the most-recommended MCP servers survive contact with a setup you already have, not just which ones install cleanly. The two highest-ranking guides on the topic don't answer that: both rank servers by popularity, built the same way, a table, an install command per row, a one-line pitch for what each server does for you. Neither says which servers people actually kept. One is literally titled "Ranked and Tested," then admits inside the article that its real advice is a rule of thumb: remove any server the agent never calls. That's a guess dressed up as a result.

So I picked the five servers that show up in almost every one of those lists: the four official reference servers (filesystem, git, memory, fetch) plus Playwright, the community server those same roundups called the most-installed right now. Then I connected the three I could reach, filesystem, memory, and Playwright, for real and measured what happened, and pulled git and fetch's tool counts from their own docs, instead of copying the table.

The plan: connecting five MCP servers in one real afternoon

The plan was simple: connect each server, ask it what tools it actually exposes, and compare that list against what Claude Code can already do on its own. Filesystem and memory install with one npx command. Git and fetch are Python packages (pip install mcp-server-git, mcp-server-fetch), both at version 2026.7.10. Playwright installs the same way as filesystem, via npx @playwright/mcp@latest.

Instead of trusting a client's UI to tell me what connected, I spoke the protocol directly: an initialize call followed by tools/list, over stdio. That gives you the server's exact name, version, and protocol revision with nothing smoothed over.

{"result":{"protocolVersion":"2025-06-18","serverInfo":{"name":"secure-filesystem-server","version":"0.2.0"}}}

That was the filesystem server's real reply. All three servers I could reach this way answered with the same protocol revision, 2025-06-18, not the 2026-07-28 spec our own server had to migrate to.

Filesystem and git: the two Claude Code already had covered

Filesystem and git were the easiest calls, because both duplicate tools Claude Code ships with by default. The filesystem server exposed 14 tools: read, write, edit, move, search, list, and a read_file tool explicitly labeled "(Deprecated)" in favor of read_text_file, a small tell that even an actively maintained reference server carries its own leftover cruft. Every one of those 14 tools maps to something Claude Code's built-in Read, Write, Edit, and Bash tools already do.

Git wasn't any different. Its server exposes 12 fixed tools (git_status, git_diff, git_commit, git_log, and so on), and its own README still describes it as "early development." Claude Code's Bash tool already runs the real git binary, with every flag git has, not 12 pre-picked wrappers around it. Trust me on this one: if your assistant can already open a terminal, a git MCP server is a smaller version of a tool you're not missing.

Memory: the one our own playbook already replaced

Memory looked the most interesting on paper and turned out to be the easiest to skip once I noticed we'd already solved that problem. The server (version 0.6.3) exposes 9 tools for building a local knowledge graph: entities, relations, and observations you create, search, and delete across sessions.

Here's the thing. Inaday.ai's own operating file already carries session memory between runs, as a single markdown file rewritten each time, capped at 500 words. It's not a knowledge graph. It's a text file that survives every restart without a separate server to keep alive. A knowledge graph is a neat trick until you remember the thing you actually needed was a file you already had.

Fetch and Playwright: the two I actually kept

Fetch and Playwright survived because neither one duplicates something Claude Code does out of the box.

Fetch is a single tool, literally named fetch, that pulls a page and converts it to markdown. That sounds small next to filesystem's 14 tools, but it does something Claude Code's own built-in web-fetch doesn't: it hands back the raw converted text, chunked with a start_index parameter for long pages, instead of running the page through a small model first and giving you a summary. When you need the exact wording on a page (a price, a changelog line, a quote for a tool review) raw beats summarized.

Playwright is the opposite kind of server: 24 real tools (browser_click, browser_navigate, browser_snapshot, browser_evaluate, browser_network_requests, and 19 more), reported at version 1.62.0-alpha during my test. Nothing in Claude Code drives an actual browser on its own. For anything that needs a real page rendered first, a login flow, a screenshot, a form your build broke, that's hours back you're not spending switching to a browser by hand.

The result: what's running on my setup now

By the end of the day, two of the five servers were still enabled.

None of the three servers I could reach directly, filesystem, memory, and Playwright, had moved to the new 2026-07-28 protocol revision either, which is a different problem than the one we hit rebuilding our own server on that same spec: three methods disappeared overnight there. Git and fetch don't state a protocol revision in their own docs, so I can't confirm those two either way. Three servers checked live, zero spec breakage among them. All the damage in this test was self-inflicted redundancy, not the protocol's fault.

Would I connect all five again?

I'd connect all five again, and disconnect the same three, because the point was never to end up with two. It was to stop assuming a server earns its spot just because a list says it's essential. If you're wiring any of this into an actual agent instead of just your own coding setup, the same logic applies to every tool you hand it: each one should earn its keep the same way I checked these five. I walked through that build separately in how to build an AI agent.

Build it once, win every week only works if the "once" includes asking what you're duplicating. Two servers cleared that bar for me. Your three might not be the same three.