skills/mcp-boundary/references/profiles/mcp-2026-07-28.md

---
profile_id: mcp-2026-07-28
profile_version: 1
assessed_at: 2026-08-15
status: current-as-assessed
language: en
language_peer: mcp-2026-07-28.zh-CN.md
---

# MCP profile: 2026-07-28

As assessed on `2026-08-15`, `2026-07-28` is the current published MCP revision. This profile is date-stamped because that claim will age; verify the official specification again when a task asks for “latest.”

## Normative sources

- [Specification index](https://modelcontextprotocol.io/specification/2026-07-28)
- [Key changes from 2025-11-25](https://modelcontextprotocol.io/specification/2026-07-28/changelog)
- [Versioning and compatibility](https://modelcontextprotocol.io/specification/2026-07-28/basic/versioning)
- [Transport overview](https://modelcontextprotocol.io/specification/2026-07-28/basic/transports)
- [Streamable HTTP](https://modelcontextprotocol.io/specification/2026-07-28/basic/transports/streamable-http)
- [Server discovery](https://modelcontextprotocol.io/specification/2026-07-28/server/discovery)
- [Official release explanation](https://blog.modelcontextprotocol.io/posts/2026-07-28/)

Normative requirements remain in the linked specification.

## Protocol shape

- The core is stateless. `initialize`, `notifications/initialized`, and protocol-level `Mcp-Session-Id` are removed.
- Every request is self-describing through `_meta`: protocol version and client capabilities travel with the request; client identity should also travel there. Server results identify the server in result `_meta`.
- `server/discover` is required on servers and allows a client to learn supported revisions, capabilities, and identity before other work.
- Servers do not initiate JSON-RPC requests and clients do not send JSON-RPC responses. Multi Round-Trip Requests (MRTR) carry input needs through `InputRequiredResult`, followed by a retry of the original request with `inputResponses`.
- Every result has `resultType`: ordinary results use `complete`; an MRTR intermediate result uses `input_required`.
- Streamable HTTP mirrors selected body metadata into required `Mcp-Method` and `Mcp-Name` headers. The body is authoritative; a mismatch is rejected.
- General GET-based server messaging is replaced by `subscriptions/listen`. Request-scoped notifications remain on the originating request's response stream.
- SSE resumability and `Last-Event-ID` redelivery are removed. A broken response stream loses the in-flight request; a retry uses a new JSON-RPC request ID.
- List/read results covered by `CacheableResult` include `ttlMs` and `cacheScope`; list order should be deterministic.
- Tasks move out of the core into `io.modelcontextprotocol/tasks`. The extension framework becomes the explicit path for optional protocol families.

## Stateless does not mean effect-free

The removal of transport sessions means any request can reach any compatible instance. It does not remove application state, durable jobs, authorization subjects, or idempotency needs.

When cross-call state is required, mint an explicit, server-owned handle and pass it as ordinary tool data. Define:

- who may possess and use the handle;
- whether it is opaque or model-readable;
- expiry and revocation;
- storage and concurrency ownership;
- retry and duplicate-effect semantics.

Do not re-create an implicit transport session under a different header.

## Streamable HTTP obligations

- Receive each request or notification as an HTTP POST to the MCP endpoint.
- Require the revision-appropriate protocol metadata and routing headers before expensive body work when the framework makes that possible.
- Compare mirrored `Mcp-Method` / `Mcp-Name` values with the decoded body before dispatch; do not authorize solely on attacker-controlled headers.
- Keep request body `_meta` authoritative and return the revision-defined mismatch error for disagreement.
- Return JSON or a request-scoped SSE stream. A disconnected HTTP response stream is cancellation/abandonment for that request under this binding.
- Do not advertise `Mcp-Session-Id`, GET resumability, `Last-Event-ID`, or the removed initialize lifecycle as if they were still active.
- Implement `subscriptions/listen` only if change-notification streams are actually owned and bounded.

## Implementation consequences

1. Dispatch cannot depend on connection-local initialization state. Validate protocol version and client capabilities on each request.
2. `server/discover` must be truthful, cheap enough to expose, and deterministic enough for compatibility decisions.
3. Header-based routing is an optimization and policy input, not a substitute for body validation. Gateways and applications need a shared mismatch contract.
4. MRTR retries require explicit operation identity. If work may have started before returning `input_required`, document whether retry resumes or restarts it.
5. Result serialization must always include the correct `resultType`; compatibility handling for an earlier server's missing field belongs on the client side.
6. Cache metadata is a disclosure and freshness decision. `cacheScope: public` must not be applied to personalized or authority-sensitive catalogs.
7. Deprecated Roots, Sampling, Logging, legacy HTTP+SSE, and Dynamic Client Registration should not be added to a new design without a bounded compatibility reason.

## Revision-bound test obligations

- Any valid request can execute on a fresh instance with no prior initialize exchange.
- Missing, malformed, or unsupported per-request protocol metadata is rejected with the revision-defined error.
- `server/discover` declares only implemented revisions, capabilities, extensions, and identity.
- `Mcp-Method` and `Mcp-Name` are required where specified and are compared with the body; mismatches never reach capability execution.
- Server-originated JSON-RPC request shapes and client-originated JSON-RPC response shapes are rejected.
- Every result has a valid `resultType`; MRTR input requests and retries preserve operation semantics.
- Broken response-stream retries use a new request ID and do not silently duplicate non-idempotent effects.
- Cacheable results include valid `ttlMs` and `cacheScope`; lists are deterministic.
- Removed sessions, initialize flow, GET stream, and SSE resumption do not remain as active compatibility theater.

## Migration boundary from 2025-11-25

Treat the migration as an architecture replacement:

1. remove lifecycle gates and session headers from the selected active path;
2. add per-request metadata validation and `server/discover`;
3. replace server-initiated request flows with MRTR;
4. replace GET/resumability designs with request-scoped streams or `subscriptions/listen`;
5. add routing-header/body consistency checks;
6. add required result and caching metadata;
7. move task support behind the official extension;
8. review deprecated features and remove unsupported capability claims.

If backward compatibility is required, isolate it as a tested adapter with an explicit revision decision. Do not merge stateful and stateless semantics into ambiguous conditionals throughout the capability core.

## Known unknowns

- Host and SDK adoption can lag the specification even when a Tier 1 SDK advertises support.
- The exact pre-dispatch hooks available for header validation depend on the HTTP framework and proxy chain.
- MRTR, extensions, and `subscriptions/listen` support must be verified against the intended host, not assumed from spec publication.
- OAuth and host-integration guidance evolves independently; use the dated [integration profile](integration-guidance-2026-08-15.md).