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

Annotations only provide negative hints (not read-only, not idempotent, not destructive). The description adds key behavioral details: the tool creates a signed timestamp, leaves the claim unmodified and unjudged, and records the source as self-declared. It stops short of specifying persistence or rate limits, but covers the core behavior.

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 compact and front-loaded, using a concrete example to explain the non-judgment nuance. Every sentence serves a purpose – core action, source caveat, verification route, and docs link – with no redundancy.

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 two-parameter tool with no output schema, the description covers the purpose, input semantics, and how to verify the result. It does not describe the proof's return format or mention authentication/rate limits, but those are not essential for correct invocation.

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?

Both parameters already have detailed schema descriptions (byte-for-byte, max 16000 chars; self-declared, not verified). The tool description reinforces these points but adds little new parameter-level meaning, so it does not elevate the baseline 3 for high schema coverage.

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 states a specific action – timestamps and signs a third party's exact claim – and clarifies it does not express agreement. It also names verify_proof as the mechanism to check the resulting proof, distinguishing it from sibling tools.

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 tool description implies its use case: witnessing a third-party claim without endorsing it, and points to verify_proof for subsequent verification. However, it does not explicitly contrast with alternatives like ledger_submit or enumerate when not to use the tool.

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