The four states of a claimed capability
- Advertised: it appears in the tool list a client can read.
- Registered: a handler exists in source and is wired to that name.
- Deployed: that version of the handler is the one currently serving traffic.
- Executed and persisted: a call ran and left a record you can open afterwards.
How the gaps appear in practice
A catalog entry is added ahead of the handler during development and never removed. A handler is written but the function is not redeployed, so the live endpoint still serves the previous build. A call returns a success envelope from a handler that swallowed a database error. None of these are exotic; all of them are invisible if you only read the tool list.
How to close them
Make the catalog and the code prove each other automatically: every advertised action must resolve to a handler and to a permission mapping, or the build fails. Then treat deployment as an explicit step with its own confirmation, and treat verification as reading the record back rather than trusting the response.