The Model Context Protocol published its 2026-07-28 specification revision, and the changelog is long. Sessions and the initialize handshake are gone, Dynamic Client Registration is deprecated in favor of Client ID Metadata Documents, and clients must now validate the iss parameter on authorization responses. Together with the spec's security best practices page, it gives you a vetting checklist that is better than a gut feeling about a GitHub star count.
This post turns that material into questions you can answer before a server goes into an engineer's config file or into an agent's tool list.
What's affected
Two groups. If you consume MCP servers, every third-party server you add runs with your client's privileges when it is local, and holds your tokens when it is remote. If you publish servers, your implementation is now judged against the revision.
Changes in 2026-07-28 that matter for vetting:
- No protocol-level sessions and no
Mcp-Session-Idheader. Servers that need state mint explicit handles passed as tool arguments. - Every request carries protocol version and client capabilities in
_meta. Servers must implementserver/discover. - Deprecated, with a minimum twelve-month window under the new lifecycle policy: Roots, Sampling and Logging, the HTTP+SSE transport, and OAuth Dynamic Client Registration (RFC 7591) as a registration mechanism.
- Authorization servers should include
issper RFC 9207, and clients must validate it before redeeming a code. Clients must key stored credentials by issuer. - Servers should return
tools/listin a deterministic order. - OpenTelemetry trace context keys (
traceparent,tracestate,baggage) are documented for_meta.
How to check if you're exposed
Walk each candidate server through the checklist below. The right-hand column is what the spec says, so you can cite it in the approval ticket.
| Check | What good looks like | Spec basis |
|---|---|---|
| Local startup command | You can read the exact command and arguments, and it does nothing beyond launching the server | Clients must show the full command and require consent |
| Sandboxing | Runs in a container or sandbox with limited filesystem and network | Clients should sandbox with minimal default privileges |
| Transport | stdio for local use, or an HTTP transport with an auth token | Servers should limit access to the client |
| Token audience | Rejects tokens not issued for this server | Servers must not accept tokens not issued for them |
| Token passthrough | Never forwards the caller's token downstream | Explicitly forbidden |
| Scopes | Small starting scope set, step-up for privileged tools | Scope minimization section |
| Wildcard scopes | No *, all or full-access in scopes_supported | Listed as a common mistake |
| Registration | Client ID Metadata Documents, not open DCR | DCR deprecated |
| State handles | Bound server-side to the verified user, unguessable, expiring | Handle hijacking section |
| Tool inputs | Validated, rate limited, outputs sanitized | Tools security considerations |
| Annotations | You do not rely on readOnlyHint style claims from the server | Annotations are untrusted unless the server is trusted |
| SSRF | Remote client blocks private ranges and metadata addresses | SSRF section |
Then do the practical checks the spec cannot do for you:
# What does the package run on install, and who publishes it?
npm view <package> scripts bin maintainers dist.integrity
# Pin by integrity, not by "latest"
npm pack <package>@<exact-version> && tar -tzf *.tgz | head -50
# Enumerate the tools it exposes, and keep the output
npx @modelcontextprotocol/inspector
Save the tools/list output. Because the revision asks servers to return tools in a deterministic order, a plain diff between two runs is a useful tripwire for a tool that changed after approval.
What to do now
- Create an approved server list. Nothing outside it goes into shared configs or agent definitions.
- For each candidate, run the table above and attach the answers to the approval request.
- Pin the exact version or image digest. Re-run the review on every upgrade, since a server can add tools in a patch release.
- Run local servers in a sandbox with no access to your home directory, SSH keys or cloud credentials unless the task needs them.
- Give each server its own narrow credential. Do not reuse a developer's personal access token.
- Remove HTTP+SSE endpoints and open Dynamic Client Registration from servers you own, and plan the move to Client ID Metadata Documents inside the twelve-month window.
- Log every tool call with the caller, tool and arguments, using the trace context keys the spec now documents.
Why it matters
A local MCP server is a program with your privileges that an AI model decides when to call. The spec's own example of a malicious startup command is a plain npx line followed by a curl that uploads ~/.ssh/id_rsa. Nothing about that is exotic. It is the same supply chain problem as any package install, with a model in the loop.
Remote servers shift the risk to tokens. Token passthrough, wide scopes and missing audience checks turn one stolen token into access across systems. The spec says so in plain terms: poor scope design increases the impact of a compromised token and makes audit trails harder to read.
The new revision also shows a healthy habit worth copying. Features are deprecated with a window and a registry, not removed overnight. Ask server maintainers whether they track that registry. A project that does is more likely to keep up with the next one.
Try it yourself
Take one server your team already uses. Fill in the table, then decide whether it would pass today. If the answer to "can I read the exact startup command" is no, start there.
Click through it at your own pace, or open it full screen.
Safeguard Gold lists MCP servers alongside packages and CVEs, which helps with the "who publishes this" question. For the Node side, the official @modelcontextprotocol/sdk package has a page there too.
Quick check
Why does the spec treat tool annotations as untrusted?
Annotations such as read-only hints are claims made by the server. A malicious or compromised server can set them to hide a destructive tool, so clients must not rely on them unless the server is trusted.
What is token passthrough and why is it forbidden?
An MCP server accepts a token and forwards it to a downstream API without checking it was issued for the server. It breaks audience checks, hides who made the call in audit logs and lets the server act as a confused deputy.
What replaces Dynamic Client Registration?
Client ID Metadata Documents. DCR remains available for backward compatibility but is deprecated in the 2026-07-28 revision.
