MCP Servers Worth Wiring In
After this you can stand up an agent's tool layer by wiring in the few MCP servers a task actually needs, and you can read the maintenance and security signals that tell you whether a given server is safe to trust before you connect it.
The instinct, once you discover MCP, is to connect everything. There are thousands of servers across half a dozen registries, and a fresh agent with a filesystem server, a GitHub server, a search server, and a database server feels powerful. The operator move is the opposite. Every server you connect injects its tool descriptions into the model's context on every single request, before the user has said anything. Connect a handful of chatty servers and you can burn tens of thousands of tokens on tool definitions alone with dozens of servers attached. That spend is not free attention sitting in reserve. The model also has to pick the right tool from the list you handed it, and selection accuracy degrades as the list grows. Hand it sixty similarly-named tools and it will sometimes call the wrong one. So more tools is not more capability. It is a tax on every turn plus a higher chance of the wrong call. The discipline is to wire in the fewest servers that cover the task and disable the rest.
The second thing to internalize is what installing a community server actually is. An npx- or uvx-launched server runs third-party code on your machine with whatever credentials you give it. Fatih Kadir Akın's "The MCP server ecosystem is a mess" names the structural problem directly. Registries have a discovery problem (none agree on what is good, duplicates and abandoned projects sit next to live ones), a quality problem (most servers are weekend projects wrapping one endpoint and returning raw JSON), and a security problem (no sandboxing by default). Inclusion on an awesome-mcp-servers list is breadth, not vetting. The card for a provider-maintained reference server, an actively-maintained community server, and a dead weekend project all look identical. So you read the signals the registry strips away before you wire anything in: who maintains it, when it last shipped, whether it scopes credentials, whether it returns shaped data or raw blobs, and how many tools it exposes.
The naive moves all fail here in their own way. Asset hoarding (connect every server you can find) produces a slow, expensive agent that picks wrong and carries a wide attack surface. Trusting a curated list as a quality signal puts an abandoned server one credential away from your data. And lift-and-shift (installing a server like a browser extension, with no scoping and no re-check after approval) leaves you open to a server that hides instructions in a tool description, or one that changes its behavior after you approved it. The shelf below is grouped by the job you are trying to do, and each entry carries the signal to read before you trust it.
The shelf is the asset. It is grouped by job, not by vendor, because you wire in by job. Each entry states the server, the job it does, and the one signal worth checking before you wire it in. Connect only the rows the task in front of you touches.
Dev (the most-wired group).
- filesystem — Anthropic reference server. Gives the agent read/write access to a directory tree. Earns its place because almost every coding or document task needs it, and the reference servers are the one corner of the ecosystem with a clear maintainer. Breaks when: you point it at a broader root than the task needs. Scope it to the project directory, not your home folder, because the agent can write anywhere it can read.
- git + GitHub — local history operations (git) versus remote repo, issues, and PRs (GitHub). Worth wiring separately because most local work never needs the GitHub API and connecting it adds tools plus a token to every call. Breaks when: the GitHub token is broadly scoped. A token that can write to every repo turns a wrong call into a real incident.
- Sentry — pulls error and stack-trace context so the agent debugs against real production signals instead of guessing. Earns its place on a debugging task and only then. Breaks when: left connected on unrelated work, where it just taxes context.
Data.
- Postgres / Supabase — query and inspect a database. The signal that separates a usable data server from a dangerous one is credential scoping. Breaks when: wired with a write-capable production credential. Default to a read-only role on a replica or the analytics database. An agent reading an untrusted issue while holding a write credential is data loss waiting to happen.
Search and docs.
- Exa / Brave / Tavily — web search and crawling shaped for model consumption rather than raw HTML. Earn their place because the model's training has a cutoff and these are how it reads the live web. Breaks when: you assume they are interchangeable. They differ sharply on cost and on what they extract (see the worked example).
- Context7 — pulls current, version-specific library and framework documentation into context. Earns its place precisely because the model's docs knowledge is stale for fast-moving libraries, so it cuts the confident-but-outdated API call. Breaks when: treated as a general search tool. It is for library docs, not the open web.
Browser.
- Playwright / Puppeteer — drive a real browser to click, fill forms, and read rendered pages. Earn their place for anything behind JavaScript or a login that a plain fetch cannot reach. Breaks when: pointed at untrusted pages while the agent also holds powerful tools. Rendered page content is untrusted input and can carry injected instructions.
Comms and commerce.
- Slack — read and post messages, useful for status and notification steps in a workflow. Breaks when: given broad write scope. A wrong post is visible to a channel instantly.
- Stripe — payments and billing data. High value, high blast radius. Breaks when: connected with anything beyond the narrowest read scope the task needs. Keep destructive payment actions behind a human gate, never auto-approved.
Reference and hosting.
- fetch — Anthropic reference server that retrieves a URL's content. The lightest way to let an agent read a known page. Breaks when: used for search; it fetches a URL you already have, it does not find one.
- memory / sequential-thinking — Anthropic reference servers for a simple persistent store and for step-by-step reasoning scaffolding. Useful, low-risk. Breaks when: leaned on as durable state. A file you own is more inspectable than a memory server's opaque store.
- Cloudflare — the reference point for hosting a remote MCP server rather than a server you consume. Relevant only when you move from a local stdio server to a remote one for multi-user distribution, which brings auth and multi-tenancy as hard requirements.
Before you wire any of them in, run the vet checklist below. It is the copy-pasteable artifact for this module. Paste it next to the server's repo and answer every line before you connect it.
Vet before you wire — answer before connecting any MCP server
[ ] Maintainer: official/provider-maintained, or a named community maintainer who responds to issues?
[ ] Last shipped: a commit/release in recent memory, or abandoned? (no decay signal in the registry — check the repo)
[ ] Tool count: a few task-shaped tools, or dozens of granular 1:1 API mirrors? (fewer is better)
[ ] Returns: filtered/shaped data, or raw JSON blobs that will blow context?
[ ] Credentials: can I give it a read-only / least-privilege / scoped credential? (never a broad write token by default)
[ ] Code trust: this runs third-party code on my machine with my creds — do I trust the source enough to run it?
[ ] Approval: am I auto-approving its tools, or keeping a human gate on destructive actions?
[ ] Exit: what symptom would make me disconnect this? (if you can't name one, you'll never remove it)Two of those lines are the ones beginners skip and operators never do. The credential line closes the largest blast radius. The exit line is the test that you are curating rather than accumulating. A stack that only grows is a stack nobody is reading the signals on.
Worked example
IllustrativeIllustrative. A constructed decision to show the vetting move, not a real run.
The job is an agent that researches companies by reading their annual reports, which arrive as table-heavy PDFs, and you are choosing the crawler for the search-and-docs row. Exa is already the shelf's pick; a teammate wants to add Firecrawl alongside it. Both demo well, both return page content the model can read, and the shelf discipline says run one crawler rather than two, so the question is which one breaks on this task.
Two signals decide it. The first is cost. The crawl runs across hundreds of reports, and the cost asymmetry between these two is roughly a thousandfold at that volume. At one report that difference is invisible. At the real scale of this task it is the difference between a trivial line item and a bill that ends the project. The second signal is extraction quality on the actual content, and this is the one the demo hides. The reports are table-heavy, and Firecrawl drops table content from PDFs. The agent would receive clean-looking prose with the numbers silently missing, which is worse than a hard failure because the agent will reason confidently over what it got and never flag the gap.
So the decision is Exa, on both signals, and the reasoning is concrete rather than a vibe:
Candidate: Firecrawl Cost at this volume: roughly 1000x Exa across hundreds of reports — disqualifying at scale. Extraction on the real content: drops table-heavy PDF content; the agent gets prose with the numbers missing and no error. Verdict: leave it off. The financial tables are the entire point.
Candidate: Exa Cost at this volume: the cheap side of the ~1000x asymmetry. Extraction on the real content: preserves the table content the task depends on. Verdict: keep it on. Scope to read-only crawling; exit signal is a quality regression on a sampled report.
The general move is in that comparison. Two servers that both pass the demo are separated by reading their cost shape at your real volume and their extraction quality on your real content, then keeping the one that survives both and leaving the other off. The shelf stays short as a byproduct of that test, applied to each server honestly.