skills/mcp-boundary/references/profiles/mcp-2025-06-18.md

---
profile_id: mcp-2025-06-18
profile_version: 1
assessed_at: 2026-08-15
status: historical-supported
language: en
language_peer: mcp-2025-06-18.zh-CN.md
---

# MCP profile: 2025-06-18

This profile describes implementations that intentionally speak MCP revision `2025-06-18`. It is historical compatibility guidance, not a recommendation to adopt this revision for a new server.

## Normative sources

- [Specification index](https://modelcontextprotocol.io/specification/2025-06-18)
- [Key changes from 2025-03-26](https://modelcontextprotocol.io/specification/2025-06-18/changelog)
- [Lifecycle](https://modelcontextprotocol.io/specification/2025-06-18/basic/lifecycle)
- [Transports](https://modelcontextprotocol.io/specification/2025-06-18/basic/transports)
- [Authorization](https://modelcontextprotocol.io/specification/2025-06-18/basic/authorization)

Normative `MUST`, `SHOULD`, and `MAY` meanings come from the specification, not this summary.

## Protocol shape

- The connection has a lifecycle: `initialize` negotiation precedes ordinary operation, and the client sends `notifications/initialized` after successful initialization.
- Streamable HTTP uses a single MCP endpoint supporting POST and GET. A request may receive one JSON object or a request-scoped SSE stream.
- A server may establish a real transport session during initialization with `Mcp-Session-Id`. If it does not own session state and expiry semantics, it should not emit a decorative or constant session identifier.
- For subsequent HTTP requests, the negotiated revision travels in `MCP-Protocol-Version`. An invalid or unsupported value is an HTTP error.
- JSON-RPC batching is not supported in this MCP revision even though base JSON-RPC 2.0 defines batches.
- Structured tool output, resource links in tool results, elicitation, OAuth protected-resource metadata, and Resource Indicators are part of this revision's change surface.

## Streamable HTTP obligations

At the MCP endpoint:

- validate `Origin` on incoming connections; for a local server, bind to loopback unless broader reachability is intentional;
- require POST bodies to contain one JSON-RPC request, notification, or response—not a batch;
- return `202 Accepted` with no body for an accepted notification or response;
- for a JSON-RPC request, return either `application/json` or `text/event-stream`;
- if GET streaming is not implemented, answer with `405 Method Not Allowed` instead of simulating SSE;
- treat `Mcp-Session-Id`, SSE resumability, and server-to-client messaging as optional features with real state obligations, not compatibility decorations.

These protocol rules do not replace HTTP framing limits, authentication, admission control, or deployment policy.

## Implementation consequences

1. Model lifecycle state explicitly enough to reject pre-initialization calls and invalid re-initialization according to the declared revision.
2. Keep a stateless implementation honest: omit `Mcp-Session-Id`, do not claim resumability, and return ordinary JSON when no stream is needed.
3. Validate message kind before dispatch. A notification may be accepted without a JSON-RPC response, but acceptance does not imply that every notification may execute a side effect.
4. Keep capability validation shared across all transports. A convenience REST route must not bypass the tool allowlist, argument schema, or resource budgets.
5. Treat negotiated `protocolVersion`, server capabilities, and tool metadata as runtime contracts reflected by tests.

## Revision-bound test obligations

- `initialize` succeeds only for a supported version and returns truthful capabilities.
- ordinary calls before initialization are rejected according to the lifecycle contract.
- `notifications/initialized` is classified as a notification and does not receive a JSON-RPC result.
- batch-shaped JSON is rejected even when a generic JSON-RPC library accepts it.
- an emitted `Mcp-Session-Id` is unique, opaque, validated on later requests, expires, and can be terminated; otherwise assert that it is absent.
- POST notification/response acceptance returns HTTP 202 with no body.
- unsupported `MCP-Protocol-Version` is rejected.
- Origin, content type, body size, incomplete-body deadline, and request-target tests are exercised at the real socket boundary.

## Migration boundary to 2025-11-25

The lifecycle and optional session model remain. The later revision adds or clarifies several features, including explicit HTTP 403 for an invalid present `Origin`, polling-style SSE behavior, URL-mode elicitation, tool-calling in sampling, Client ID Metadata Documents, and experimental tasks. Do not backport those requirements merely by renaming a version constant.

## Migration boundary to 2026-07-28

This is a breaking architecture change, not a small schema bump. The later revision removes protocol-level sessions and the initialize handshake, makes every request self-describing, removes server-initiated JSON-RPC requests, adds `server/discover`, requires HTTP routing headers, and changes streaming/cancellation semantics. Use the [2026-07-28 profile](mcp-2026-07-28.md) and rewrite lifecycle tests instead of forcing both eras through one state machine.

## Known unknowns

- Host products may implement only a subset of this historical revision.
- SDK defaults and compatibility shims are not proof of wire-level behavior.
- Authorization requirements depend on whether the server is remote, who owns the resource server, and which issuer is authoritative.
- Any claim about a deployed endpoint remains unverified until exercised through its actual proxy, TLS, authentication, and host path.