Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already provide readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the description doesn't need to restate those. It adds 'No commercial obligation; Risk R0; PUBLIC', which is useful safety/access context, but doesn't describe behavior for missing IDs or response details. Overall it supplements annotations without contradicting them.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely concise: one action sentence plus two clarifying tags. It is front-loaded with the core operation and contains no filler. Every segment earns its place, and the structure makes the tool's purpose instantly scannable.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple single-parameter read operation, the description covers the essentials: what it reads, how it is identified, and that it is safe/public/no-obligation. It does not detail return format or error behavior, but with no output schema and strong annotations, the missing pieces are minor. The only notable gap is lack of guidance on what to do if the contract doesn't exist.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description carries the full burden for parameter meaning. 'By stable identifier' clarifies that the 'id' parameter is a stable identifier, which is more than the bare schema provides. However, it lacks format guidance, examples, or how to obtain such an identifier, leaving the agent with minimal practical guidance.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb ('Read') with a clear resource ('canonical capability contract') and method ('by stable identifier'). The singular 'one' distinguishes it from the sibling 'get_axiom_capabilities', which likely lists contracts. The added context 'No commercial obligation; Risk R0; PUBLIC' makes the operation's nature unmistakable.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage: use this tool when you have a stable identifier and need a single capability contract. However, it doesn't explicitly state when not to use it or point to alternatives such as get_axiom_capabilities for listing or find_paid_service for commercial discovery. 'No commercial obligation' hints at boundaries but doesn't direct the agent to siblings.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.