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

Consistent with readOnlyHint=true, and it adds real behavioral context beyond annotations: no account or token is required, and 'full checks run in the background and are rate limited.' The remaining ambiguity is whether the call blocks for the verdict or returns before background checks finish — that matters for an agent that wants to gate on the result.

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-loaded purpose, then explicit 'When to use' and 'Notes' sections — efficient and scannable. The trailing 'Example arguments: {}' for a zero-parameter tool is filler and slightly dilutes the signal.

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?

There is no output schema, so the description should say what comes back; 'return the verdict' is asserted but its shape (boolean, status enum, failure details) is undescribed. The preconditions (auth-free, rate limited) are well covered, so the gap is confined to the response.

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?

Zero parameters, so the baseline is 4; 'Example arguments: {}' correctly signals a no-argument call. There is nothing more to document, so this dimension cannot score higher on added meaning.

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?

Specific verb plus resource plus the exact artifacts examined: 'Verify the ledger's hash chain, fingerprints and city signatures and return the verdict.' An agent immediately understands this is an integrity attestation over ledger data, distinct from read_ledger (retrieval) and the other check_* tools (which target packages, HTTP, semver).

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?

'Use before relying on ledger rows as evidence' gives a clear triggering condition, and the caveat 'Integrity does not prove that content is true' sets a crucial expectation boundary. It stops short of naming read_ledger as the companion tool or stating when to skip verification (e.g. already-verified rows), so it is clear context but not full routing guidance.

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