Session 12. MCP architecture and primitives — Tue 29 Sep

Quick quiz (ungraded)

resources: 0, like any other server with no resources
That makes a broken claim indistinguishable from a server that never claimed anything. Two different states, one line of output.
Advertised, and empty — a claim with nothing behind it
Correct. It announced a capability and serves none of it: a wrong catalogue row, a half-finished deployment, or a permission you were not granted. Naming it is what lets somebody go and ask.
Drop the resources capability, since it turned out to be false
Then the map agrees with the collections and the disagreement disappears. The disagreement is the finding.

Yes — the handshake and the listing disagree either way
They disagree in the harmless direction. Nothing was promised, and the resources are there to use.
No. Nothing was claimed, so nothing is broken; count the resources and move on
Correct. Advertised-but-empty is a promise with nothing behind it. Unannounced-but-present is an untidy handshake and two usable resources.
No, and the resources should be ignored because they were not announced
Ignoring a capability the server actually serves throws away working tools to punish a formatting slip.

It returns unsigned bytes; nothing moves until something else signs them and submits them
Correct. It is the tool that looks most dangerous and is not, which is the point of reading a surface instead of ranking it by name.
It is read-only, like the other ten
It is not read-only. It builds a transaction — it just cannot make one happen.
Its annotation says so
An annotation is a claim. The reason is what the tool returns: bytes that need a signature and a submission before anything changes.

Nothing. A tool that writes should be flagged
Then every write tool on every server is flagged, and the list of refusals stops being read. This one is honest: its name says write and it writes.
The rule matched a word instead of a disagreement
Correct. 'Creates' only matters against a claim to only read. Without the claim there is no conflict, and a benign tool refused is a capability lost and a rule somebody switches off.
The description should not name what the tool does
Describing what a tool does is a description doing its job. The problem is a description that gives orders, not one that is specific.

So a caller can count, filter and diff the verdicts without reading prose
Correct. Same argument as stopped_because in session 5 and the failure buckets in session 9: a verdict a caller can branch on, one that survives being run over fifty tools.
Because a sentence would be too long to log
Length is not the issue. A short sentence is still something only a human can act on.
Because the model reads the reasons and needs them short
The reasons are for your application, not for the model. The model never sees the tool this refused.