Repository navigation
[C10.4] 10.4.8 moved from L2 to L3 when it was merged with the schema-signing requirement #1201
Description
History
- After the C10 levels review (Levels review C10 #929, 15 June), the snapshot control was 10.4.5 at L2: "MCP clients maintain a hash or versioned snapshot of tool definitions and that any change to a tool definition (via
notifications/tools/list_changedor between sessions) triggers re-approval…". Schema signing was a separate requirement, 10.4.8 at L3, which Levels review C10 #929 described as research-grade. - In Update 0x10-C10-MCP-Security.md #946 (18 June) the two were consolidated. The snapshot text was kept, the signing requirement was dropped, and the result carried L3. The scope "via
list_changedor between sessions" was removed as well.
I couldn't find a discussion of the level change, so I'm asking whether L3 was intended. If the requirement no longer asks for signatures, the reason #929 gave for L3 no longer applies, and the control has the same shape as 10.4.10 (bind consent to the approved endpoint, re-approve on change), which is L2.
Why it matters
In October 2026 I measured eight AI coding clients after an approved MCP tool's description changed mid-session. None asked for approval again. With notifications/tools/list_changed, four fetched the new definition, three of them without telling the user; after a restart, all but one used it without asking. That restart result is also why the removed "between sessions" wording matters: it is where the changes were accepted silently.
Method and data: https://paolocostanzo.github.io/approved-mcp-tools-can-change-after-you-say-yes/
Proposal
- Restore L2 for 10.4.8.
- Restore the scope removed in Update 0x10-C10-MCP-Security.md #946: changes detected via
notifications/tools/list_changedand between sessions, i.e. on everytools/list, including after a reconnection. - Optionally, state what counts as the tool definition (name, description, input schema, annotations).
Happy to add the measurement to the C10 research page if that helps.
Activity
jmanico commentedon Oct 24, 2026
Good catch. I support moving 10.4.8 back to L2 and making the reconnect/restart case explicit. 🙏
The history supports your concern: #929 put snapshot/change detection at L2 and schema signing at L3. #946 removed signing but kept the surviving control at L3. I don't see a documented reason for that level change, so I wouldn't assume it was intentional or accidental.
Saving an approved definition, comparing it when fetched again, and blocking a changed tool until re-approval is practical L2 work. Trail of Bits' mcp-context-protector already implements this on connection and tool-list change notifications. We also put endpoint-change re-approval at L2 in 10.4.10. This fits that same principle: approval needs to stay tied to what was approved.
I'd suggest this for 10.4.8, L2, targeting 1.02-dev:
Restarting the client should not give a changed tool a free pass. 😎 This wording keeps the implementation open while making that expectation testable.
For verification, change only the description while keeping the tool name the same. Confirm the call is blocked until re-approval, then repeat across a restart. We should also cover schema and annotation changes; if we spell out the definition fields, let's include the output schema too.
One limit worth keeping clear: this detects changed definitions. It cannot detect a server changing its implementation behind an identical definition.
I think this is a meaningful, focused correction for 1.02. Thanks for digging into both the history and actual client behavior.
ottosulin commentedon Oct 24, 2026
My opinion: L2, restore the scope. And this was an editing mistake, not a level decision.
About PR #946 - the diff shows a swap. Before it: 10.4.5 snapshot at L2 (text including
notifications/tools/list_changedand "between sessions"), 10.4.8 schema signing at L3. #946 deleted both signing requirements, and the two levels moved in opposite directions: the snapshot inherited L3 from the row it was merged into, and tool-response signing dropped from L3 to L2 (10.4.6 today).About leveling
The strongest case for L3 is the state of implementations today: none of the eight measured clients does it, and the protocol does not require it. Prevalence is not difficulty. Hashing a definition, comparing it and prompting is a small change for anyone creating an MCP client.
Few proposals to the suggested text:
Suggested revised text for 10.4.8:
Suggested glossary entry to support this and avoid lengthy requirement text:
Ideally include this correction in release notes if we remember, pointing this was an error and as part of correcting the error the requirement was revised as well for clarity.
jmanico commentedon Oct 24, 2026
I defer to you @ottosulin and I think we are ready to go here. Care to give us a PR? Want me to take it on?
Add Tool Definition to the glossary (OWASP#1201)
Align the C10.4.8 row in Appendix B (OWASP#1201)
paolocostanzo commentedon Oct 25, 2026
Thanks @jmanico @ottosulin. Otto's revision works for me, including tools with no approved definition and checking the definition at the point of use. I had the change ready in advance (I was away from home yesterday and wanted it prepared in case the issue was accepted), so I've opened #1204, not to get ahead of anyone, just to save you duplicate work. It has Otto's text at L2, the Tool Definition glossary entry and the aligned Appendix B row. Happy to adjust anything in review; I hope it helps. I'm finishing further research with tests in this same area and will keep you posted.
Apply review wording to C10.4.8 and add title to Tool Definition (OWA…
[1.02] Revise 10.4.8 and restore Level 2 (#1201)