DEV Community: Gustavo

The 2026-07-28 MCP Spec: A Server Readiness Checklist

Gustavo — Fri, 19 Jun 2026 15:15:56 +0000

The next Model Context Protocol specification, 2026-07-28, is the largest revision since the protocol launched. The release candidate locked on May 21, 2026, and the final spec publishes on July 28. It contains breaking changes to transport, authorization, and how tool schemas are handled.

A server that is correct against 2025-11-25 today is not broken. Nothing here is a present-tense vulnerability. But several of these changes are security properties, not just compatibility ones — request routing integrity, cross-user cache scope, and schema-driven fetch behavior all move under this revision. This checklist walks the changes a server operator needs to handle before July 28, and calls out the security implication wherever there is one.

Everything below describes the release candidate. Treat specifics as subject to change until the July 28 final, and validate against the official spec before shipping.

Transport: the stateless core

This is the headline change. MCP becomes stateless at the protocol layer, and most of the migration work lives here.

The handshake and session are gone

The initialize/initialized handshake is removed (SEP-2575). Protocol version, client info, and client capabilities no longer get exchanged once at connection time — they travel in _meta on every request. The same SEP adds server/discover as the new discovery anchor: servers must implement it, and clients fetch server capabilities from it when they need them up front. Once the handshake is gone, a server that can't answer server/discover can't be negotiated with.

The Mcp-Session-Id header and the protocol-level session it carried are also removed (SEP-2567). Any request can now land on any server instance. The sticky routing and shared session stores that horizontal deployments relied on are no longer required at the protocol layer.

If a server needs state across calls, mint an explicit handle from a tool — a basket_id, a browser_id — and have the model pass it back as an ordinary argument. The state becomes a visible tool input rather than something hidden in transport metadata.

Required routing headers

The Streamable HTTP transport now requires Mcp-Method and Mcp-Name headers (SEP-2243), so load balancers, gateways, and rate-limiters can route on the operation without reading the body. Requests also carry MCP-Protocol-Version.

Servers must reject requests where the headers and the body disagree. This is a request-integrity check, not just a convenience: a mismatch between the routing header and the actual method in the body is exactly the kind of ambiguity that smuggling and confused-routing attacks exploit. Enforce the agreement; don't route on the header and execute the body.

Checklist

Accept self-contained requests that carry protocol version, client info, and capabilities in _meta
Implement server/discover for capability negotiation
Stop depending on Mcp-Session-Id and stop requiring sticky sessions
Require Mcp-Method and Mcp-Name, and reject header/body mismatches
Move any cross-call state to explicit, model-visible handles

Server-to-client requests

A stateless protocol still needs a way for a server to ask the client for something mid-call. Two changes rebuild that flow without a persistent connection.

Elicitation only during active processing

Server-initiated requests may now only be issued while the server is actively processing a client request (SEP-2260). Earlier versions recommended this; it is now required.

The security value is concrete. A user is never prompted out of nowhere, and every elicitation traces back to an action they or their agent started. An unsolicited server-initiated prompt is now a spec violation, which makes a whole class of social-engineering-via-prompt behavior detectable rather than ambiguous.

Multi round-trip results

Instead of holding a Server-Sent Events stream open, the server returns an InputRequiredResult carrying an opaque requestState (SEP-2322). The client gathers answers and re-issues the original call with inputResponses and the echoed requestState, and any instance can pick the retry up.

Treat requestState as untrusted on the way back in. It leaves the server, sits client-side, and returns. Integrity-protect it — sign or encrypt it — so a modified requestState can't replay or escalate a half-finished operation. Don't deserialize it into trusted server state without verification.

Checklist

Issue server-initiated requests only while handling a client call
Return InputRequiredResult rather than holding an SSE stream open
Integrity-protect requestState and verify it on retry

Caching and tracing

Three smaller changes make the resulting traffic easier to operate — and two of them carry data across boundaries that deserve attention.

Cache scope is a tenancy boundary

List and resource-read results now carry ttlMs and cacheScope, modeled on HTTP Cache-Control (SEP-2549). Clients learn exactly how long a tools/list response stays fresh and whether it is safe to share across users.

cacheScope is where this becomes a security decision. If a server exposes a per-user or per-tenant tool surface but marks the result shareable, a client may serve one user's tool list to another. Set cacheScope to match the actual sensitivity of what the response reveals, and default to the narrower scope when unsure.

Trace context propagation

W3C Trace Context propagation in _meta is now documented, fixing the traceparent, tracestate, and baggage key names (SEP-414). A trace can follow a call through the client SDK, the server, and whatever the server calls downstream, and show up as one span tree in an OpenTelemetry-compatible backend.

baggage is the field to watch. It propagates arbitrary key-value data downstream by design, which is useful and also a path for sensitive values to cross into systems that shouldn't see them. Decide deliberately what goes into baggage, and strip or scrub it at trust boundaries rather than forwarding everything.

Checklist

Emit accurate ttlMs on list and resource-read results
Set cacheScope to match per-user or per-tenant sensitivity
Use the fixed trace key names, and control what baggage carries across boundaries

Authorization hardening

Six SEPs align the authorization spec more closely with how OAuth 2.0 and OpenID Connect are deployed. These matter most to operators who run their own authorization server or broker auth in front of a server.

Authorization servers should supply the iss parameter on authorization responses per RFC 9207 (SEP-2468). Clients are now expected to validate it, and in a future version they will reject responses that omit it. This is a low-cost mitigation for a mix-up attack that is more likely in MCP's single-client, many-server pattern — so begin supplying iss now if you don't already.

The remaining changes are smaller but worth handling together: support the OpenID Connect application_type during Dynamic Client Registration so desktop and CLI clients aren't defaulted to "web" and rejected (SEP-837); bind registered credentials to the issuing authorization server's issuer and re-register when a resource migrates (SEP-2352); document how to request refresh tokens from OIDC-style servers (SEP-2207); and follow the clarified scope-accumulation and .well-known discovery rules (SEP-2350, SEP-2351).

Checklist

Supply iss on authorization responses
Honor application_type in Dynamic Client Registration
Bind credentials to the issuer and re-register on resource migration
Follow the documented refresh-token, scope-accumulation, and discovery rules

Tool schemas

Tool inputSchema and outputSchema are lifted to full JSON Schema 2020-12 (SEP-2106). Input schemas keep the type: "object" root but now allow composition (oneOf, anyOf, allOf), conditionals, and references ($ref, $defs). Output schemas are unrestricted, and structuredContent can be any JSON value rather than only an object.

Two constraints in this change are security constraints, and the spec states them as requirements. Implementations must not auto-dereference external $ref URIs — a schema that points $ref at an external URL is an SSRF and unbounded-fetch vector if you follow it. And implementations should bound schema depth and validation time, because a deeply nested or recursive schema is a denial-of-service input. If your server validates against client-supplied or third-party schemas, enforce both.

Separately, the error code for a missing resource changes from the MCP-custom -32002 to the JSON-RPC standard -32602 Invalid Params (SEP-2164). If any code matches on the literal -32002, update it.

Checklist

Accept JSON Schema 2020-12 input and output schemas
Never auto-dereference external $ref URIs
Bound schema depth and validation time
Return -32602 for missing resources, and update any matching on -32002

Deprecations

Roots, Sampling, and Logging are deprecated under the new feature lifecycle policy (SEP-2577). These are annotation-only deprecations: they keep working in this release and in every spec version published within a year, and removal requires a separate SEP. There is no forced cutover on July 28 — but plan the replacements now.

The documented replacements are tool parameters, resource URIs, or server configuration in place of Roots; direct integration with an LLM provider API in place of Sampling; and stderr (for stdio transports) or OpenTelemetry in place of Logging.

Checklist

Inventory any use of Roots, Sampling, or Logging
Plan migration to the documented replacements before the lifecycle clock runs out

Extensions

Extensions are now first-class (SEP-2133). They are identified by reverse-DNS IDs, negotiated through an extensions map on client and server capabilities, and versioned independently of the specification.

Two official extensions ship with this release. Tasks graduates from an experimental core feature to an extension with a redesigned, stateless lifecycle: a server answers tools/call with a task handle, and the client drives it with tasks/get, tasks/update, and tasks/cancel. tasks/list is removed (SEP-2663) because it can't be scoped safely without sessions. Anyone who built against the 2025-11-25 experimental Tasks API needs to migrate.

MCP Apps (SEP-1865) lets servers ship interactive HTML interfaces that hosts render in a sandboxed iframe. Tools declare their UI templates ahead of time so hosts can prefetch, cache, and security-review them before anything runs, and every UI-initiated action goes through the same audit and consent path as a direct tool call.

Checklist

Negotiate extensions through the extensions capability map
Migrate any experimental Tasks usage to the extension lifecycle
If shipping a UI, declare MCP Apps templates ahead of time for host review

What to do now

The ten-week window between the May 21 lock and the July 28 final exists for exactly this: validate the changes against real workloads before they become normative. Start a migration branch if you operate a remote MCP server, run your own authorization, or build against the experimental Tasks API. The transport rework is the largest piece; the auth and schema constraints are the ones with security teeth.

Most of these are checkable from outside the server — the routing-header enforcement, the cache scope on list responses, the $ref handling, the iss parameter. Gated inspects deployed MCP servers against these and the rest of its check library, mapping each to the conformance and security families with a reproduction for every finding — including private and internal servers reached from inside your network. If a security team wants the posture of a server in writing before July 28, that's the kind of thing it produces.

— Gustavo, Gated

Auditing an MCP Server Against the OWASP MCP Top 10

Gustavo — Tue, 09 Jun 2026 20:43:56 +0000

Auditing an MCP Server Against the OWASP MCP Top 10

The OWASP MCP Top 10 is now the taxonomy people reach for when they talk about MCP risk. It is the framework a security team will bring into a procurement conversation, and the one practitioners increasingly cite by number. It is still a beta — Phase 3, under active community revision — but the categories are stable enough to design an audit around.

So here is the practical question. You operate an MCP server. Someone hands you the Top 10 and asks how you stand against it. What does an audit actually check, category by category?

Eight of the ten are testable against a running server. The remaining two are not really about a single server at all — they live in the build pipeline and in org-level governance. That split is most of the work, so it is how the rest of this is organized.

A note on what "testable" means here. An audit from the network sees the deployed endpoint, with its real auth, its real TLS, its real manifest — not a config file on a developer's laptop. That vantage point decides which risks an audit can reach. It is the difference between reading what a server claims and observing what it does.

The eight an audit covers

MCP01 — Token Mismanagement and Secret Exposure. This is the risk that credentials leak through the protocol surface: tokens in URLs, secrets echoed in tool output, access tokens with no sane expiry, credentials written into log notifications. Every one of those is observable. An audit sends real requests and reads what comes back — whether a token survives in a response body, whether the access-token lifetime is bounded, whether an error path quietly returns the credential it just rejected.

MCP06 — Prompt Injection via Contextual Payloads. MCP turns tool descriptions, prompt templates, and resource content into a second instruction channel pointed at the model. A description that contains an injection string, an invisible Unicode payload, or a known jailbreak phrase is a finding you can read straight off the manifest — no execution required. This is the part of the framework that maps most cleanly onto passive inspection, because the attack lives in text the server already serves.

MCP07 — Insufficient Authentication and Authorization. The largest testable surface, and the one with the least ambiguity. Does an unauthenticated caller get rejected? Do administrative tools require identity? Is PKCE enforced on the authorization code flow? Are expired, invalid, and revoked bearer tokens actually turned away, or does any non-empty token open the door? These are concrete request-response facts. A server either rejects the malformed call or it doesn't.

MCP02 — Privilege Escalation via Scope Creep. Scope creep is harder to catch than missing auth, because it is about permissions that are technically granted but quietly too broad. The audit examines the OAuth contract: whether granted scopes match what was requested, whether resource indicators are enforced, whether the scopes a server advertises are the scopes it honors. That catches the server that hands back more than it was asked for.

MCP05 — Command Injection and Execution. A scanner can't see your shell. What it can see is whether the server validates the inputs that would feed one. Does it reject undeclared properties, enforce declared types, hold string and array bounds, refuse path traversal in resource URIs? Input validation is the observable proxy for injection resistance, and a server that enforces its declared schema closes the door that most injection walks through.

MCP10 — Context Injection and Over-Sharing. When context is shared across sessions or agents, one task's data can surface in another's. The audit probes isolation between authorization contexts: whether task records leak across identities, whether task IDs are guessable on a no-auth deployment, whether an elicitation form quietly collects more than it should. These are boundaries you can test by holding two identities and checking what one can see of the other.

MCP03 — Tool Poisoning. Tool poisoning is an adversary corrupting the tools, interface definitions, or outputs a model depends on. It has three observable forms, and the audit reads all three. Schema poisoning and malicious descriptions show up in the manifest on the first read — the audit checks descriptions, parameter definitions, and namespaces the way the model will, before an agent acts on them. Rug pulls — a trusted tool that changes its description after you approved it — are caught by fingerprinting each tool on first sight and re-verifying that fingerprint on every reconnect, so drift becomes a finding rather than a surprise. Tool shadowing, where one server impersonates another's tools, surfaces when the audit compares tool and namespace claims across the set of servers an agent can reach.

MCP08 — Lack of Audit and Telemetry. The framework calls for disciplined logging of tool invocations and context changes. From the network, the audit checks the hygiene of that telemetry: that log notifications don't carry credentials, that log levels come from the standard set, that the logging surface follows the spec rather than leaking internal state. Good telemetry that quietly exfiltrates secrets is its own finding, and this is where it surfaces.

The two that live at a different layer

MCP04 — Software Supply Chain and Dependency Tampering. This category is about signed components, dependency provenance, and catching a tampered package before it ships. It is a build-pipeline and SBOM concern by nature — the integrity question is settled at build time, in your CI and artifact signing, not at the running endpoint. A network audit flags adjacent signals like disclosed framework and runtime versions; the provenance work belongs upstream where the dependency tree actually lives.

MCP09 — Shadow MCP Servers. The risk here is the server nobody told the security team about — spun up for a demo, running default credentials, never inventoried. This is a discovery and governance problem: by definition it is about the servers an organization doesn't yet know it has. The lever that helps most is making the audit of known internal servers cheap enough to run everywhere, so bringing a server into governance stops being a chore.

What to take from this

Most of the OWASP MCP Top 10 is testable against a running server, and the testable part skews toward the risks that have produced real CVEs this year — auth gaps, token exposure, injection through tool descriptions. That is the part an audit gives you a clean, reproducible answer on.

The remaining two are worth naming precisely. Supply-chain integrity is settled in your build pipeline; shadow servers are a discovery problem that sits above any one endpoint. The framework is most useful when you know which layer each of its risks belongs to, and which tool in your stack owns it.

CTEM covers your whole attack surface. Except the part your AI agents use.

Gustavo — Wed, 03 Jun 2026 22:46:31 +0000

If you run a CTEM program, you have a map of your attack surface. Endpoints, identities, cloud configuration, exposed services — all scoped, ranked, and worked on a cadence.
I'd put money on the MCP servers your agents call all day not being on it.
Not because someone decided they didn't matter. Because nobody scoped them in — the tooling that draws your map doesn't know they exist. That blind spot is the whole subject of this post.

A new exposure class, not a new category of risk

MCP is how an AI agent reaches into your systems — the wiring that lets it read a ticket, query a database, or call an internal API on someone's behalf. Each server you stand up adds capability, and every capability is reachable by whatever drives the agent. Stack enough of them and you've built a second attack surface that nothing in your current toolchain was ever pointed at.

The reason this fits CTEM rather than demanding a program of its own is that the failure modes are familiar. A poisoned dependency buried in a server's package tree. A credential pasted into a tool definition. A tool that executes with broader privilege than the caller ever had. None of that is exotic — it's the catalog you already know, moved to a layer your SAST pipeline doesn't parse and your CSPM doesn't enumerate. The pipeline doesn't see a hosted MCP server at all. The CSPM has no idea which tools an agent is allowed to call.

It's the shadow-IT story again, one layer up the stack: capability arriving faster than anyone's ability to see it.

Mapping MCP onto the five CTEM phases

The useful thing about CTEM is that you don't need a new program to handle MCP. You need to extend the one you have. Each phase has a clear MCP equivalent:

Scoping. Add MCP servers to the surfaces you care about — public-facing endpoints and the private, internal servers behind your firewall, which is where most real exposure lives.
Discovery. Inventory the servers, the tools each one exposes, and the data those tools can surface. You can't assess what you haven't enumerated.
Prioritization. Rank findings by what an attacker could actually reach, not by raw count. A toxic flow that exfiltrates data outweighs a cosmetic schema warning.
Validation. Confirm that a finding is exploitable, with a reproduction an engineer can run — the difference between a theoretical issue and one worth a sprint.
Mobilization. Hand engineering remediation they can act on without a second meeting, and hand audit and compliance a record they can stand behind.

The phases that usually get skipped for MCP are discovery and validation. Discovery, because no one owns the inventory. Validation, because a list of maybes doesn't survive contact with an engineering backlog.

What discovery actually requires for MCP

A list of server hostnames isn't an inventory. The exposure lives a layer down — in the tool definitions, the parameter schemas, the authorization model, and the data each tool will hand back when an agent asks for it.

Industry research on exposure management is blunt about the cost of getting this wrong: most identified exposures turn out to be dead ends, and most remediation effort has historically gone to issues that never threatened a critical asset. Discovery that stops at the hostname guarantees you spend that effort in the wrong place. Reach the tool and schema level, and prioritization finally has something real to sort.

Where Gated fits

Gated is the audit layer for the MCP servers your agents already reach into. It scans deployed, hosted servers — not developer-machine configs — across security, quality, conformance, reliability, and cost, and returns ranked findings with reproductions for every one.
Two things make that fit a CTEM program rather than sit beside one.
One is that discovery and validation happen in the same pass. Gated enumerates the tools and schemas a server exposes, runs its checks against them, and produces a reproduction for each finding — so the output drops straight into prioritization and mobilization instead of stalling at "needs triage."

The other is that the scanning suits a regulated environment. Private and internal servers are reached through a proxy; the checks run on Gated infrastructure, and no metadata leaves your network. For teams under LGPD, SOC 2, or similar obligations, the audit record — reproducible findings, provenance on every suppression — is itself a deliverable.
Gated doesn't make you compliant. It closes the MCP gap in the program you already run, and gives you the evidence to show it's closed.
Scan your first Server