MCP crossed from “interesting RFC” into “paste this server into your agent.”
GitHub READMEs, Discord drops, and one-click installs now ship tools that can read files, hit HTTP, and sometimes run shell. That is power. It is also the same surface that ate API keys in every other plugin ecosystem.
What is actually shipping
A Model Context Protocol server exposes tools and resources to a host (Claude Code, IDE agents, custom runtimes). The host decides which servers attach. The model decides which tools to call. Your job is everything between those two sentences: allowlists, auth, and blast radius.
Community servers move fast. Pin a commit or a release tag. “Latest” is how supply-chain surprises arrive.
Minimum hardening before attach
- Run the server as a separate process with the least filesystem and network it needs.
-
Allowlist tools — if the server offers
run_shell, leave it off until you have a reason. - Inject secrets at the edge — the model should not see raw keys; the host or a proxy injects them into approved calls.
- Log every tool call with args redacted. You will need the trail.
// sketch: only expose a subset of tools from an MCP server
const allow = new Set(["search_docs", "get_issue"]);
for (const tool of server.listTools()) {
if (!allow.has(tool.name)) continue;
host.registerTool(wrapWithAudit(tool));
}
MCP vs a custom tool adapter
| MCP server | In-repo tool adapter | |
|---|---|---|
| Speed to try | Fast | Slower |
| Versioning | External | Yours |
| Review | Often thin | PR-reviewed |
| Fit when | Shared protocol across hosts | Critical side effects |
Use MCP to explore and to standardize. Keep money movement, production deploys, and secret rotation in first-party adapters until the server has the same review bar as your services.
Honest trade-off
Blocking community servers slows experimentation. Opening them without a sandbox is how you buy someone else’s bug. The middle path is a staging host with fake credentials and a recorded allowlist, then promote servers the same way you promote libraries.
Practical checklist
- [ ] Pinned version / commit
- [ ] Network egress limited
- [ ] Tool allowlist reviewed in a PR
- [ ] Secrets never in model context
- [ ] Audit log on every invocation
Which MCP servers in your stack could delete data today if the model asked nicely?
Top comments (1)
Good checklist. One addition to the allowlist step: a server can change its tool list after you've reviewed it (the protocol has a list-changed notification for exactly that), so it helps to re-check the list on every connect and fail closed if a tool shows up that isn't on your approved set. It's also worth treating tool descriptions and tool results as untrusted text, since they get read by the model and can carry injected instructions even from a server you trust. Pinning the version plus diffing the tool schemas on upgrade covers both pretty well.