You are right, and thank you for the precision. I checked the 2025-03-26
schema and ToolAnnotations is there with all four hints, so "no read-only
mode, no scoping" is simply wrong as written. I will correct that paragraph.
The schema comment is even blunter than the spec page you quoted: "Clients
should never make tool use decisions based on ToolAnnotations." So the flag
exists, and the spec itself tells clients not to trust it. Which lands
exactly where you put it: the annotation is advisory, the two-config
separation is the only thing that actually binds.
Taking the point about annotating anyway. If some clients surface
destructiveHint in a confirmation UI, that is free safety for the users on
those clients, and it costs nothing for the ones that ignore it.
Good to hear lesson four matched. The attention-tax framing is better than
mine.
Small correction on the protocol claim, because your config-level advice is right for a subtler reason than stated. You write "There is no notion of a tool requiring confirmation, no read-only mode, no scoping," but MCP has had tool annotations since the 2025-03-26 spec revision: readOnlyHint, destructiveHint, idempotentHint, openWorldHint. The catch, and it validates your approach, is that the spec marks them as untrusted hints unless the server itself is trusted, and clients are not required to enforce them. So a read-only flag exists on paper and your two-config separation is still the only enforcement that actually binds. Worth annotating your tools anyway, since some clients do surface destructiveHint in confirmation UIs. Lesson four matched my experience exactly: trimming payloads to what the model reasons over improves answers, not just cost, because the model was reading past those fields and paying attention-tax for the privilege.