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

No annotations exist, so the description carries the full burden and does well: ordering (newest first), the signing/verification model (each event signed by MolTrust and independently re-verifiable offline via moltrust-verify against GET /canary/trust-list), pagination semantics, and the API-key auth requirement. It does not state error or rate-limit behavior, keeping it just short of a 5.

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?

Front-loads the most important facts (what the events are, ordering, authenticity model) before the Args block. The Args list partially restates signature-level info, but since the schema has no descriptions those lines earn their place; still slightly padded.

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, so return-shape detail is unnecessary, and the description covers auth, ordering, verification path, and all three parameters. It leaves out failure modes (invalid canary_id, offset past the end) but is otherwise sufficient to call the tool 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?

With 0% schema description coverage the description must carry all three parameters, and it does: canary_id is scoped to one canary and sourced from canary_issue/canary_list, limit is page size capped at 200, offset is the page start. It adds real meaning the bare schema does not, though it could specify units or behavior for out-of-range values.

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 verb+resource ('Your leak events, newest first') plus the defining traits: MolTrust-signed and carrying AER material. It names related siblings (canary_issue, canary_list, moltrust-verify) so an agent can place it in the workflow, though it never explicitly contrasts it with canary_list or molcheck_evidence as the alternative source of related data.

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 gives real operating conditions — scope it to one canary optionally, page size capped at 200, and the X-API-Key auth requirement on the MCP connection — but never says when to reach for this tool versus canary_list or the molcheck_*/moltrust_verify siblings. Usage context is implied rather than routed.

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