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

With no annotations provided, the description carries the full burden of behavioral disclosure, and it excels. It reveals that anchoring is batched and never immediate, that 'pending' is a normal state for up to ~5 hours, defines 'last_anchored' as the most recent on-chain attestation, and states that everything is independently checkable. This gives an agent a precise mental model of the tool's behavior and edge cases, going far beyond a simple 'returns data' statement.

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 a single paragraph but meticulously organized: it leads with the core purpose and endpoint, then details the payload, then explains the critical batching caveat with clear emphasis ('ANCHORING IS BATCHED, NEVER IMMEDIATE'), then defines last_anchored and anchoring, and closes with reassurance of verifiability. Every sentence adds essential information; there is no filler or redundancy. The structure front-loads the most important facts and progressively deepens context.

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 absence of an output schema and annotations, the description must fully equip an agent to call and interpret results. It does: it lists all returned components, explains the 'pending' vs. real txid semantics, defines last_anchored and anchoring, and reassures that results are independently verifiable. An agent can confidently invoke the tool and correctly parse the response without additional documentation.

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?

The tool has zero parameters, so the baseline is 4. The description does not need to explain parameters; instead, it clarifies the output semantics (the meaning of fields like bsv_txid, last_anchored, and anchoring), which is the appropriate focus. Since there is nothing to add about parameters, this score reflects that the description fully satisfies the parameter-semantics dimension by not having any.

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 verb and resource: 'returns the latest hourly PUBLIC transparency attestation (GET /transparency/latest — no auth)'. It enumerates exactly what is included (Merkle root over balances, total supply, transaction attestation, state root, Bridge Ledger root, BSV transaction) and distinguishes it from the 'pending' state. No sibling tool overlaps with this purpose, so differentiation is inherent, but the description is unambiguous.

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?

It clearly indicates when to use this tool (to obtain the latest transparency attestation) and explains the batching cadence, so an agent knows what to expect. It doesn't explicitly say when not to use it or mention alternatives, but the context is sufficient: the anchoring behavior and the meaning of 'pending' are explained, which guides correct interpretation. It would benefit from naming siblings like ledger_verify or verify_proof for cross-referencing, but that's not strictly necessary.

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