[sstriker]

Summary

MCP 2026-07-28 removes the initialize handshake and the Mcp-Session-Id header. Each request carries its protocol version and client capabilities in _meta. Servers must answer server/discover, and each result carries resultType.

The memory server and the egress use rmcp 3.5.0, which already speaks 2026-07-28. Three parts of crates/memory speak MCP without rmcp, and they spoke only 2025-06-18 with the handshake. This change moves them to 2026-07-28. Each part still works with clients and servers that use the handshake.

• mcp_meta.rs (new) holds what the three parts share: the versions, the _meta of a request, the MCP-Protocol-Version, Mcp-Method and Mcp-Name headers, and the check of resultType. A result without resultType is complete. A result with a different value is an error.
• tool_server.rs (amem tool-server) answers both types of client.
  • A request that names a version in _meta, or server/discover, goes to the new path. On this path, the server refuses a request without a version (-32602), with a version that it does not speak (-32022, with the versions that it speaks), or with headers that are missing or do not agree with the body (-32020).
  • Each result on the new path has resultType: "complete". server/discover and tools/list also give ttlMs: 0 and cacheScope: "private".
  • initialize stays. It now answers with the version that the client asks for if the server speaks it, else with 2025-11-25. Before, it gave back any version that the client asked for, also 2026-07-28.
  • On both paths, the server compares Mcp-Method and Mcp-Name with the body when the client sends them, and refuses a difference (-32020).
  • A body that is not one JSON object, such as a batch, gets HTTP 400 and -32600. Before, it got 202 and the server ignored it.
  • When a request names an older version in _meta, the -32022 answer lists only 2026-07-28, and says that the older versions use initialize.
• mcp_http.rs, the hook client in the sandbox, sends one tools/call with _meta and the headers. Before, it sent three requests. It talks only to the memory server of this project, so it does not ask for the version first.
• hosted.rs, the client for tool servers in other places, first sends server/discover.
  • If the server lists 2026-07-28, the client sends one tools/call.
  • If the server lists only older versions, the client uses initialize as before. It also uses initialize after a 400, 404, 405, 415 or 422 without a 2026-07-28 error, or after a -32601 answer. An older rmcp server answers 422 or 415 to a request without a session.
  • Any other answer, such as a 502, a 429, or a 401, is an error. The client does not keep it.
  • The client keeps the answer for each server URL until a call fails.
  • After initialize, the client now sends the MCP-Protocol-Version header. The 2025-06-18 version of the spec requires it, and the old code did not send it.

Choices where the spec gives options

• On the new path, a request without Mcp-Method or Mcp-Name is refused. The spec lists a missing required header as a failure. On the old path, a missing header is accepted, because older clients do not send these headers.
• hosted.rs sends server/discover first. It does not try tools/call first. A server that does not check sessions could run a new call under its old rules.

Tests

Test	Run against	What it reported
tool_server::tests::discovery_names_every_version_spoken_and_the_tools	main	left Null, right "complete"
tool_server::tests::a_stateless_request_is_served_and_its_result_says_it_is_complete	main	left Null, right "complete"
tool_server::tests::an_unsupported_version_is_refused_naming_the_supported_ones	main	left 200, right 400
tool_server::tests::headers_missing_or_at_odds_with_the_body_are_refused	main	left 200, right 400
tool_server::tests::a_client_that_opens_with_initialize_is_answered_as_before	main	left "2024-11-05", right "2025-11-25"
hosted::tests::a_reply_is_read_from_json_or_an_event_stream, the input_required case	main	unwrap_err() on an Ok value
mcp_http::tests, the resultType assertion	main	left Null, right "complete"
tests/hosted.rs a_server_of_the_stateless_revision_is_called_without_a_handshake	main	the tool server answered 400: -32601, "no initialize here"
tests/hosted.rs a_server_from_before_the_stateless_revision_is_called_after_the_handshake	a client that does not fall back	the tool server answered 400: "no session"
hosted::tests::what_a_server_speaks_is_read_from_its_answer_to_discovery	the same	left Ok(Stateless), right Ok(Handshake)
a_server_from_before_…_after_the_handshake	a client that does not send MCP-Protocol-Version after initialize	the tool server answered 400
mcp_http discovery check	a discovery request without the headers	left 400, right 200, -32020
a_name_header_at_odds_with_the_body_is_refused_after_a_handshake_too	774bd66	left 200, right 400, and the fetch tool ran under the name search
an_answer_to_discovery_that_names_no_revision_is_an_error_and_not_kept	774bd66	a 502 page was taken as an older server, and the client sent initialize
what_a_server_speaks_is_asked_once_and_again_after_a_call_fails	a client that asks before each call	left 2, right 1
the same	a client that keeps the answer after a failed call	left 1, right 2
a_body_that_is_not_one_request_is_refused_as_invalid	774bd66	left 202, right 400
an_unsupported_version_is_refused_naming_the_supported_ones, a _meta with 2025-06-18	774bd66	supported listed all four versions

The unit tests of mcp_meta are new, and no run showed them failing.

The tests that use initialize 2025-06-18 still pass: tests/hosted.rs, curation.rs, launch.rs and the egress tests.

Checks

• make check passes: 752 tests.

Open

• scripts/conformance.py, its fake server, and scripts/demo/mcp.py still use initialize. rmcp keeps the old path, so they still work.
• PLAN.md:48 says that amem serve answers initialize. This is a note of an earlier state.
• The paper cites MCP 2026-07-28 after docs: correct the incident account, and name MCP 2026-07-28 and A2A #48.

Adversarial pass

A fresh agent attacked the first commit. It found:

1. On the handshake path, a request whose Mcp-Name did not agree with the body still ran.
2. The hosted client took any answer to server/discover that it could not read, such as a 502 page, as an older server, and kept that answer.
3. No test held the per-URL answer that the client keeps.
4. The tool server ignored a batch and answered 202.
5. The -32022 answer listed a version that it had just refused.

The last commit corrects these. No pass ran after it.

Two findings are not changed. They were in the code before this change:

• The hosted client takes the first message with an id from an event stream, and does not compare the id with the request.
• The hosted client does not support x-mcp-header, which 2026-07-28 requires of a client. A tool server that uses it refuses each call with -32020.

Second review round

Copilot found three problems, and f8c0f29 answers them. Two were real. The third named the server, but the fault was in our client, which encoded Mcp-Method. A separate agent reviewed the full branch, because Copilot had run out of quota. Its verdict was merge. c261007 closes the two gaps that it found:

• Test cases now show that error codes -32700 and -32600 clear the cached revision.
• The hook client refuses a header value that has a control byte. The method header is no longer encoded, and the request is written as raw text.

Each new test failed on a version of the code without its fix.

make check passes on the branch with main merged: 757 tests.

Posted by Claude on behalf of @sstriker

[Copilot]

🟡 Changes recommended

Protocol handling retains stale cache entries after response-validation failures, accepts unsupported discovery result types, and rejects valid encoded method headers.

3 open issues

• Reject unsupported result types during protocol discovery · New
• Clear cached protocol after response parsing or validation failures · New
• Decode Mcp-Method before comparing it with the request body · New

What changed in this PR

This PR updates the three hand-written MCP components in crates/memory to 2026-07-28, following the protocol documentation update in #48.

Changes:

• Adds shared request metadata, header encoding, and result validation.
• Adds stateless tool-server requests and hosted-client discovery, while retaining legacy handshake support where needed.
• Converts hook calls to one stateless request and adds protocol compatibility tests.

File	Description
crates/​memory/​tests/​hosted.rs	Tests stateless calls and legacy handshake compatibility.
crates/​memory/​src/​tool_server.rs	Adds discovery, request validation, and stateless results.
crates/​memory/​src/​mcp_meta.rs	Defines shared protocol metadata, headers, and result checks.
crates/​memory/​src/​mcp_http.rs	Sends hook calls as single stateless requests.
crates/​memory/​src/​main.rs	Registers the shared MCP module.
crates/​memory/​src/​hosted.rs	Adds protocol discovery, caching, and legacy fallback.
crates/​memory/​Cargo.toml	Adds the Base64 dependency for header encoding.
Cargo.lock	Records the binary’s Base64 dependency.

_{Review effort: Balanced}

[sstriker]

Fixed in f8c0f29. Discovery now runs mcp_meta::complete on a result that lists supportedVersions. A result of another kind is an error, and the client does not cache it. The test a_discovery_result_of_a_kind_not_taken_is_refused_and_not_kept failed on the old code, because the call succeeded.

Posted by Claude on behalf of @sstriker

[sstriker]

Fixed in f8c0f29. A 200 reply now clears the cached revision in these cases:

• the reply does not parse;
• it has no result and no error;
• its result is not an object, or has an unsupported resultType;
• its error has no code, or the code is -32700, -32600, -32601 or a 2026-07-28 error.

A tool error (isError, -32602, -32603, or a server code) keeps the cache, because it concerns the call, not the revision. The test a_reply_not_of_the_revision_kept_asks_again_and_a_refused_call_does_not covers each case. A later commit adds the -32700 and -32600 cases.

Posted by Claude on behalf of @sstriker

[sstriker]

The server is correct here, and our client had the fault. The 2026-07-28 transport allows the Base64 sentinel only for Mcp-Name and Mcp-Param-{Name}: "For headers that permit the Base64 sentinel encoding (Mcp-Name and Mcp-Param-{Name}), servers MUST decode encoded values". So a server compares Mcp-Method as sent. Our client encoded Mcp-Method, and f8c0f29 stops that. The test a_method_header_is_compared_as_sent_and_never_decoded keeps the server rule. The test the_method_header_carries_the_method_as_it_is covers the client. A later commit makes the hook client refuse a header value that has a line break.

Posted by Claude on behalf of @sstriker