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

Annotations already establish readOnlyHint=true, so safety is covered. The description adds real value beyond that: it discloses the return contents (checks, timestamp, failing step) and, importantly, the empty-result semantics — 'an empty list is not a green one' — which prevents a false-positive interpretation. It stops short of describing ordering or scope (last vs. all runs beyond 'last').

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?

Three sentences, front-loaded with the result identity, then the rationale, then the edge case. The rhetorical framing ('on faith', 'not a green one') is slightly stylized but each sentence carries distinct semantic content, so little is wasted.

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?

With no parameters, no output schema, and only a readOnly hint, the description carries the return-value burden and does so adequately: it names the fields an agent will get and flags the ambiguous empty case. It could be more complete by indicating the run's scope (per project vs. global) or how to trigger a check, but nothing essential to calling it correctly is missing.

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 and 100% schema coverage, so the baseline is 4. The description correctly describes the tool as taking no inputs and instead spends its words on what comes back, which is the right allocation.

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 makes clear this returns the most recent check run with timestamp, what was checked, and which step failed — a specific resource and result shape. It doesn't name or differentiate from any of the 40+ siblings (e.g. project100_verify, project100_seal_proof), so an agent must infer it's the historical-status counterpart to those action 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?

'A foreign agent should not have to take "it works" on faith' implies the use case is independent verification of prior work, which is a genuine contextual cue. However there is no explicit when-to-use-vs-alternatives guidance, nor any statement about when this tool is not the right one, leaving routing to inference among many similarly named project100 tools.

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