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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The phrase 'without deterministic outcome claims' is the one behavioral signal the description contributes, but it is too vague to tell the agent what the output guarantees or refuses to do. No mention of latency, dependencies, required evidence inputs, or failure modes.

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 single sentence is short, but brevity here reflects under-specification rather than conciseness: it is a fragment that repeats the tool name and carries no actionable content. Nothing is front-loaded because there is nothing substantive to front-load. This mirrors the calibration case where a one-word 'Process' description scored low on this dimension.

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 10-parameter tool with a branch-conditional input schema and an output schema, a single fragment sentence is wholly inadequate. Even granting that the output schema can explain return values, the agent still has no idea what evidence sources are consulted, what the ledger aligns, or how this differs from the many audit/journal siblings. Nothing an agent needs in order to invoke it correctly is present.

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 description coverage is only 30% across 10 parameters, and the description provides no parameter information whatsoever — no mention of date, time, place, coordinates, timezone, topics, or the anyOf branch requiring either 'place' or latitude/longitude/timezone. With low coverage, the description was obligated to compensate and does not. The one input constraint the description could clarify, the exclusive place-vs-coordinates requirement, is left entirely to the schema.

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 is essentially a restatement of the name and title: 'Evidence-linked build claim evidence ledger' adds no verb or resource framing beyond what the tool name already says. The only extra semantic content is a negative qualifier ('without deterministic outcome claims'), which describes an epistemic stance rather than what the tool produces. It does not distinguish this tool from auditing siblings such as audit_reading_evidence or audit_prediction_claim.

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?

There is no statement of when to use this tool, when not to, or which sibling to prefer. With roughly a dozen adjacent evidence/claim/journal tools (audit_prediction_claim, audit_reading_evidence, build_prediction_journal), the absence of any routing guidance leaves the agent to guess. The description is silent rather than misleading, so it lands at the low end of the scale rather than 1.

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