MCP 2026-07-28 removed sessions: the v0.3 MCP profile needs a different correlation anchor #324

Activity

1. Mayur021 commented on Sep 14, 2026

   

   Mayur021

   on Sep 14, 2026

   Last edited by Mayur021

   Member

   More actions

   Both anchors correlate calls. There is a second binding the profile has to choose, and 2026-07-28 made it harder rather than easier.

   Before SEP-2567, tools/list varied per connection, so a session carried an implicit snapshot of what the tools claimed to do. That is gone, and there is no handshake left to pin one to. At verification time nothing says what the called tool was declared to do at the moment it was called.

   tool_transcript.hash binds which tools were called, with what parameters and responses. It does not bind the contract they were called under. That stops being academic once the protocol is stateless, because declarations move underneath.

   We measured this. 35 crawls of the public MCP registry between June and August 2026, 44,172 tools on 2,043 servers. 83.8% of tools declare at least one canonical effect annotation, and 59.3% hold a declaration still bound to an unmutated contract. The gap is 24.5 points, and it stays between 21.6 and 24.7 across every threshold tested. Over the longest uninterrupted 21-day window, 18.3% of the declaring and judgeable tools saw a confirmed contract mutation. The corpus holds 783 confirmed declaration changes, and 86.0% of first declarations land on the permissive pole. All four annotation defaults are restrictive, so that move produces no change event for a monitor to fire on.

   The consequence here is that a Level 1 record can verify cleanly and the relying party still cannot tell whether the tool that ran means now what it meant then.

   Suggestion for the profile: require a digest over the declaration set in force at call time, the canonicalized tools/list result, carried in the transcript and covered by tool_transcript.hash. Section 3.2 already reaches this case where it says the canonicalization rule covers a bridge profile's declaration and tool-call digests, where no schema constrains the input. The mechanism is there. The profile is where it becomes required.

   Method and data: https://doi.org/10.5281/zenodo.22649163
2. madeinplutofabio commented on Sep 17, 2026

   

   madeinplutofabio

   on Sep 17, 2026

   More actions

   I think this issue has two separable bindings, not one.

   The first is the correlation anchor after MCP removed protocol-level sessions. traceparent / tracestate and server-minted handles are both plausible ways to correlate a flow or call family, but neither tells a verifier what the called tool was declared to mean at call time.

   The second is the declaration snapshot. I agree with @Mayur021 that the v0.3 MCP profile should bind the tool declaration set, or at least the relevant tool declaration, as it existed when the call was made. Otherwise tool_transcript.hash can bind the call name, arguments, and response while leaving the called contract movable.

   The existing PIC/TRACE bridge is a useful local precedent for the separation, without making this a PIC dependency. It keeps the authorization artifact, declaration digest, tool-call digest, and transcript/successor evidence separate:

   • declaration digest: what the action was declared to be;
   • tool-call digest: what was actually invoked;
   • authorization decision: whether that declared action was allowed;
   • transcript/successor evidence: what execution evidence was later observed.

   I think the MCP profile needs the same separation of concerns:

   • correlation anchor: “which flow / call family is this?”;
   • declaration snapshot digest: “what tool contract was this call made against?”;
   • policy or authorization evidence, when present: “what decision or policy frame governed this call?”;
   • transcript hash: “what call and response were recorded?”.

   That would avoid recreating the old MCP session object under another name, while still giving a verifier enough evidence to survive stateless MCP and mutable tool declarations.

   A small non-normative cleanup could also make the current text less session-shaped before the profile is drafted:

   • change tool_transcript.call_count descriptions from “tool calls in this session” to “tool calls in this transcript” in schema/trace-claim.json and schema/trace-claim-v0.3-draft.json;
   • clarify in §3.3.3 that “session” there means a TRACE/cMCP receipt stream or producer-defined execution scope, not an MCP protocol session.
3. Mayur021 commented on Sep 17, 2026

   

   Mayur021

   on Sep 17, 2026

   Member

   More actions

   The separation is right, and the schema already has the precedent for it. policy.bundle_hash is described as the digest of the policy bundle in force at execution time, sitting as its own object beside tool_transcript. A declaration digest in force at call time is that same shape applied to a different artifact, so this is symmetry rather than a new mechanism.

   Two things on the shape, one of which I think matters more than it looks.

   Separation of concerns should not become separate signing. tool_transcript.hash is described as bound into the EAT envelope. If the declaration digest sits beside the transcript hash rather than inside what the envelope covers, a producer can present a transcript that verifies while the declaration digest moves, which is the same movability one level up. Whichever field it lands in, it needs to be inside the signed set.

   On "the declaration set, or at least the relevant tool declaration", I would keep the set. A digest over the canonicalized tools/list costs what a digest over one entry costs, one hash, so the narrower form saves nothing. It does lose something: the agent chose from the list, not from the entry, so a description change elsewhere in the set can move the selection without touching the called tool's own declaration. In the corpus the movement that matters is a property of the set rather than of any single row. 86.0% of first declarations land on the permissive pole, and because all four annotation defaults are restrictive, that move produces no change event at all on the entry a narrow binding would cover.

   Both non-normative cleanups are worth doing. call_count reads "tool calls in this session" in both trace-claim.json and trace-claim-v0.3-draft.json, and disambiguating "session" in 3.3.3 from an MCP protocol session removes the last place the text still assumes the construct 2026-07-28 deleted.
4. madeinplutofabio commented on Sep 18, 2026

   

   madeinplutofabio

   on Sep 18, 2026

   More actions

   @Mayur021 Agreed on both refinements.

   On signing: yes, the declaration-set digest only helps if it is inside the signed evidence envelope. Otherwise it creates the same movability problem one layer above the transcript.

   On scope: your argument for the full canonicalized tools/list set is stronger than the narrower "relevant declaration" form. I used the narrower wording to avoid over-specifying the profile too early, but I agree the set is the safer evidence boundary: the agent selected from the set, and movement elsewhere in the set can change the meaning of that selection.

   So the profile shape I would now read as:

   • correlation anchor for the flow or call family;
   • signed declaration-set digest for the tool contract surface in force at call time;
   • transcript hash for the recorded call / response;
   • policy or authorization evidence only when a profile chooses to bind that layer.

   The small wording cleanups seem independently useful and non-normative.
5. imran-siddique commented on Sep 24, 2026

   

   imran-siddique

   on Sep 24, 2026

   MemberAuthor

   More actions

   The MCP changelog confirms the session removal and new request IDs on retries. For the draft, keep TRACE's receipt-stream identity distinct from MCP transport state. Record each request attempt separately; an OTel context or server handle can link attempts, but neither establishes authorization, execution or completeness.

   Keep the declaration-set digest inside the signed record, separate from the transcript digest. The draft needs to specify the retained declaration bytes and canonicalization, including pagination and changes between discovery and dispatch. A digest alone does not establish which declarations the agent actually saw.

   Please start with the session-wording cleanup and a small profile example covering a lost response, retry and changed declaration set. Leave absent outcomes unknown. That gives us a concrete basis for the v0.3 binding rules without changing v0.2 semantics.
6. opento-suggestions

   added a commit that references this issue on Oct 12, 2026

   Merge remote-tracking branch 'origin/main' into docs/digest-algorithm…

   ...

   b4ca325
7. imran-siddique commented on Oct 15, 2026

   

   imran-siddique

   on Oct 15, 2026

   MemberAuthor

   More actions

   Closing. #413 now defines a TRACE session as the receipt stream, and #423 added the retry and declaration-snapshot example, which were the two things my 09-24 comment asked for. The normative MCP profile sits on the ROADMAP and gets its own issue when someone picks it up.
8. imran-siddique

   closed this as completedon Oct 15, 2026