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

Annotations already declare readOnly/idempotent/non-destructive, and the description adds beyond them: no API key needed, the descriptor is hash-verifiable, and it is identical to /.well-known/agent.json. It does not cover error behavior, but this is a simple read with rich annotations, so the added context earns a strong score.

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?

Three sentences with the most actionable facts front-loaded: no auth requirement and what it fetches. The 'call this now' phrasing is slightly promotional and the final validation instruction is procedural, but overall the description is compact and readable.

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 zero-parameter read-only tool with an output schema, the description is complete: it covers auth requirements, data returned, equivalence to a known endpoint, and the validation workflow. Nothing required to call it correctly is missing.

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?

There are zero parameters and the input schema already states that the owner derives from the authenticated principal. Per the 0-param baseline, the description has no obligation to explain parameters and adds no parameter-specific details.

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?

States a specific action and resource: 'Fetch the hash-verifiable AgentContractV1 descriptor (version + schema_url + schema_hash) and the hosted_runtime facts', and anchors it to the /.well-known/agent.json equivalent. This is precise enough to distinguish from siblings without opening schemas.

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 gives explicit context for when to call it: 'before acting', and notes no API key is required. However, it does not name alternatives or exclusions, even though sibling verify_contract exists for contract validation.

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