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

The annotations already declare readOnlyHint=true, and the description corroborates rather than contradicts that. It does add genuine behavioral context beyond the annotation: the answer is sourced from the external issuer proof.holdings, implying a remote dependency an agent may need to account for. It says nothing about failure modes when the issuer is unreachable or how fresh the status is.

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?

A single dense sentence front-loads the core claim and then enumerates what is returned, with the read-only/no-args note trailing. There is no filler, though the clause structure ("as answered by proof.holdings, its issuer") is slightly awkward to parse on first read.

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?

An output schema exists and carries the return shape, and a zero-parameter schema carries the inputs, so the description only needs to convey purpose and provenance. It does both, and correctly avoids restating the return fields' structure or the schema.

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, so the baseline is 4, and the description reinforces it with "takes no arguments". No further parameter meaning is possible or needed here.

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?

"Reports whether this server's Proof of Delegation holds" gives a specific verb (reports) and resource (Proof of Delegation status) and enumerates the returned facts: status, delegating principal, delegate, expiry. It also names the authoritative responder (proof.holdings, its issuer), which separates it from a purely local check. It stops short of naming a sibling such as get_proof_status or verify_delegation, so differentiation still requires a glance at the catalog.

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 only usage statement is "Read-only; takes no arguments," which is about invocation cost, not about when to choose this tool. With siblings like get_proof_status, get_delegation, get_proof_token and verify_delegation in scope, no condition is given for preferring this one. The agent must infer the use case from the noun phrase alone.

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