Why the registry cannot be just a catalog
A list of tools can tell a model that a search function exists. It cannot tell the execution engine whether the search sends data outside the device, whether the result is read-only, or whether the task budget allows the call.
A capability card adds those properties and turns a tool into a governed execution option.
The fields that matter first
These fields let the system filter candidates before the model plans. They also make the plan’s choices explainable to the user.
- Input and output schema.
- Side effect: read-only, local write, external send, paid, or irreversible.
- Data boundary: whether data may leave the device and to which approved destination.
- Cost and latency expectations.
- Timeouts, retry policy, health, and confirmation policy.
One contract across different protocols
MCP, OpenAPI, CLI, and local adapters expose capabilities in different formats. The adapter layer normalizes them into a common capability contract so the execution engine does not need to understand every protocol directly.
This separation lets the tool ecosystem evolve without allowing protocol details to bypass governance.
The card is also an audit unit
When a capability is invoked, the execution event can reference its card, version, parameters, cost, destination, and result. The later review can connect the output to the conditions under which it was produced.
That is the difference between a tool call and a governed capability invocation.