What MCP 2026-07-28 Changes for Synaptic Cloud

What MCP 2026-07-28 changes for Synaptic Cloud

The Model Context Protocol shipped its 2026-07-28 revision, the largest change to the protocol since it launched. It removes the initialize handshake, removes protocol-level sessions, and makes every request self-contained. Synaptic Cloud's hosted MCP gateway now defaults new project bindings to that revision, and the engine behind it speaks both eras.

For most customers the practical effect is short: your editor connects with one fewer round trip, and promoting a new graph no longer knocks live clients off mid-session. The rest of this article explains why, because the reasons say something useful about how the hosted path is built.

How a hosted MCP request travels

Three layers sit between an editor and a project graph:

1. The client. Any MCP-capable tool, pointed at the project endpoint with a personal access token:

   {
     "mcpServers": {
       "synaptic": {
         "type": "http",
         "url": "https://synapticgraph.com/api/mcp/projects/<project-id>",
         "headers": { "Authorization": "Bearer ${SYNAPTIC_MCP_TOKEN}" }
       }
     }
   }
   

2. The gateway. It authenticates the synmcp_ token, confirms the token carries mcp:connect, checks that the user is an active member with a seat on a plan that includes hosted MCP, applies per-address and per-token-per-project rate limits, resolves the project's engine binding, and validates the payload against the hosted runtime policy before anything reaches an engine.

3. The engine. An isolated Synaptic core holding that project's promoted graph snapshot.

Federations get the same treatment on /api/mcp/federations/<federation-id>, resolving a multi-repository graph instead of a single project.

Every request is logged as metadata (method, tool name, status, duration, bytes in and out) and surfaces in the dashboard under recent MCP traffic. The graph content itself is never part of that ledger.

The session was the fragile part

Under the older protocol, the gateway could not be a pure proxy. initialize created a session on the engine, and the gateway had to own that mapping:

• Mint a public session id (synmcp_sess_...) and store a hashed row in mcp_gateway_sessions pointing at the upstream engine session.
• Enforce a session TTL and a per-token cap on concurrent sessions.
• Bind each session to an engine generation: the binding id, the instance id, and the snapshot id together. If any of the three changed, the session was no longer valid against the engine actually answering, so the gateway deleted the row and returned 404 with "initialize a new session."

That last rule was correct and it was the most common source of visible disruption. Promoting a new graph, or a runtime redeploy, changes the snapshot or instance id. Every connected client then had to notice a 404 and handshake again. Clients that handled it well recovered quietly. Clients that did not surfaced an error in the middle of somebody's work.

Under 2026-07-28 there is no session to lose. Each request carries its own protocol version, capabilities, and client identity in params._meta, so it can be authenticated, routed, and answered on its own. The gateway writes no session row, enforces no session TTL, and applies no per-token session cap. A promoted graph changes which snapshot answers the next request, and nothing has to be re-established first.

Two smaller wins come with it. There is one less database write on the connection path, and there is no initialize plus notifications/initialized exchange before the first useful call, so the first query_graph of a session arrives sooner.

The gateway still keeps the full legacy path, sessions included, for clients on 2025-11-25 and 2025-06-18. The project dashboard shows which era each binding is using: Stateless POST or Session POST.

A smaller hosted surface

Synaptic Cloud does not proxy MCP traffic verbatim. Every hosted request and response is validated and re-serialized against a strict policy (graph-only-v2) in both directions. Unknown fields are rejected rather than passed through, and a response that does not fit the schema fails as a bad gateway rather than reaching the client.

The move to the stateless revision made that surface smaller. Compare the allowed JSON-RPC methods:

Era	Allowed methods
Legacy	initialize, notifications/initialized, notifications/cancelled, ping, tools/list, tools/call
2026-07-28	server/discover, tools/list, tools/call, notifications/cancelled

Six methods become four. initialize and ping are gone because the protocol no longer needs them: discovery is an explicit RPC, and liveness is answered by any request.

The tool allowlist is unchanged and deliberately narrow: nineteen read-only, graph-contained tools (query_graph, affected, find_callers, find_references, shortest_path, structural_search, predict_edit, dynamic_hazards, audit_sql, and the rest), each with per-argument type and range bounds enforced before the request leaves the gateway. Tools that execute commands or touch a filesystem, such as speculate and get_source, are not part of the hosted surface at all.

Modern results get the same treatment on the way back. The gateway re-emits only resultType, _meta, ttlMs, and cacheScope; clamps ttlMs to at most 24 hours; and rebuilds server/discover results with a canonical supported-version list and bounded instructions.

One detail is specific to hosting. The revision requires clients to declare io.modelcontextprotocol/clientCapabilities on every request. The hosted transport has no client callback channel, so the gateway preserves the required declaration but forwards it as an empty object. The engine cannot ask a hosted client for anything, and now it cannot be told that it could.

Routing and metering from headers

Modern HTTP requests must carry MCP-Protocol-Version, Mcp-Method, and, for named operations, Mcp-Name. The gateway validates all three against the JSON body, forwards them upstream, and exposes them in its CORS preflight. A disagreement between headers and body is rejected as JSON-RPC -32020 before any engine work happens.

This matters more for a hosted product than for a local server. The gateway already records which method and which tool each request used; under the old protocol that meant parsing the body to find out. The same facts now arrive in headers, which means routing, rate limiting, and per-tool metering can happen at the edge without inspecting a payload. Rate limits are already applied per token and project; header routing is what lets that kind of policy move outward as the fleet grows.

Caching that reduces billable chatter

Every list result in the new revision carries a freshness hint. tools/list returns nineteen tool definitions with full JSON Schemas, and it is the largest response the hosted surface produces. server/discover results are cacheable for an hour, list results for minutes, with cacheScope marking whether a shared intermediary may hold them.

For a metered endpoint this is a direct saving. Every tools/list a client skips is a request that does not consume the token's rate-limit budget and does not appear on the tenant's usage. The second-order effect is larger: a stable, deterministic tool list that a client can hold across reconnections is a stable prompt prefix, so those tokens stay in the model provider's prompt cache instead of being re-billed on every turn.

To be precise about where the caching happens: the gateway itself still returns Cache-Control: no-store, because responses are tenant-scoped and authorization-dependent. The ttlMs and cacheScope values are hints for the client that holds the credential, not permission for a shared cache in between.

What Synaptic Cloud does not use

An honest list matters as much as the feature list.

• Multi Round-Trip Requests. MRTR replaces server-initiated requests with an input_required result the client answers on retry. Hosted engines make no server-to-client requests, so every hosted result is resultType: "complete".
• subscriptions/listen. The new streaming change-notification channel is not part of the hosted allowlist. Hosted MCP is request and response over JSON, POST and DELETE only. Graph freshness on Cloud is handled by promoting a snapshot, not by pushing notifications to editors.
• Tasks. Tasks moved into an optional extension. There are no task-backed hosted operations, so no extensions are advertised.
• Roots, Sampling, Logging. All three are deprecated in the new revision and none were part of the hosted surface.
• OAuth changes. The revision hardens OAuth (RFC 9207 issuer validation, application_type on registration, credentials bound to their issuer) and deprecates Dynamic Client Registration in favor of Client ID Metadata Documents. Synaptic Cloud authenticates with personal, project-scoped bearer tokens issued from the dashboard and tied to a licensed user, so none of it applies today. It is the relevant standard to follow if hosted MCP later offers an OAuth flow.

What to do about it

If your client is current, nothing. Point it at the project endpoint from the MCP access page and it negotiates the stateless path.

If your client is older, also nothing. 2025-11-25 and 2025-06-18 remain supported end to end, sessions included. Note that Cloud accepts a narrower set of versions than the standalone engine does: 2025-03-26 and 2024-11-05 are not accepted by the hosted gateway.

If you call the endpoint directly, a modern request looks like this:

POST /api/mcp/projects/<project-id>
Authorization: Bearer synmcp_...
MCP-Protocol-Version: 2026-07-28
Mcp-Method: tools/call
Mcp-Name: query_graph
Content-Type: application/json
Accept: application/json

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "tools/call",
  "params": {
    "name": "query_graph",
    "arguments": { "question": "where is billing enforced" },
    "_meta": {
      "io.modelcontextprotocol/protocolVersion": "2026-07-28",
      "io.modelcontextprotocol/clientCapabilities": {},
      "io.modelcontextprotocol/clientInfo": { "name": "my-client", "version": "1.0" }
    }
  }
}

Headers must agree with the body. DELETE is legacy-only and returns 405 for a modern version, since there is no session to terminate. Responses keep the existing hosted error contract: 401 with a WWW-Authenticate challenge for an invalid credential, 402 with a billing link when a seat is required, 403 for a credential scoped elsewhere, 404 for an unknown project or endpoint, 429 when a rate limit is reached, and -32020 for a header and body mismatch.

Summary

The protocol moved toward the shape hosted MCP already wanted. A project graph is shared, read-only, and keyed by project and snapshot rather than by connection, so the session layer was pure overhead that also created the most visible failure mode: a promoted graph invalidating live clients. Removing it takes out a database write, a TTL, a concurrency cap, and a class of reconnection errors, while the new routing headers and cache hints make the hosted path cheaper to operate and cheaper to use.

New project bindings default to 2026-07-28 today. Existing clients keep working unchanged.

References

• The 2026-07-28 Specification
• Key changes since 2025-11-25
• Feature lifecycle and deprecation policy