Prove an object is really stored (client-side)

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

Annotations already indicate readOnlyHint=true, and the description adds substantial behavioral detail: it trusts nothing from the coordinator, challenges each provider, recomputes the merkle root locally, checks signatures, and reports per-provider results. It also discloses the return value semantics ('how many providers proved possession right now and whether any returned bad data'), going well beyond the annotations.

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 front-loaded with the core purpose, then delivers mechanism, trust behavior, parameter guidance, and return semantics in a compact, well-organized paragraph. Every sentence adds distinct value; there is no filler or tautology.

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?

Given the read-only annotations, only two parameters, full schema coverage, and no output schema, the description is complete: it explains what the tool does, how it behaves cryptographically, when local_path is needed, and what the call returns. An agent has everything needed to invoke it correctly.

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 coverage is 100%, so the baseline is 3. The description adds useful meaning beyond the schema by explaining that objects stored through this server need no extra arguments and that local_path is used to prove possession against a local file instead. This contextual guidance helps the agent decide how to populate the optional parameter.

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 opens with a precise verb and resource: 'Independently verify that the network still holds an object, without downloading it.' It then details the mechanism (challenging providers, recomputing merkle root, checking signatures), which clearly distinguishes verify from siblings like get or ls.

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 clear context for when to use verify: for independent possession proofs, and specifically distinguishes the local_path case as only needed for objects this server did not upload. It does not explicitly name exclusions or sibling alternatives, but the context is sufficient for an agent to select it appropriately.

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