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

The description asserts 'Read only.', while the annotation sets readOnlyHint=false, which declares the call is not read-only. This is a direct contradiction between the prose and the structured safety metadata, and an agent deciding whether the call is safe would be misled. Under the annotation-contradiction rule this scores 1 despite the otherwise informative mode/status disclosure.

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 with what the tool does, then the read-only claim, then the critical two-mode caveat. Dense but every sentence carries operational weight. The standalone 'Read only.' sentence is the one questionable element, and it is also the source of the annotation conflict.

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 output schema, the description carries the burden of explaining returns and does so: it names status values (VERIFIED_RECEIPT_ONLY, VERIFIED), the verified flag, and the receipt_integrity vs memo_verified distinction. Authentication context is covered by the schema's actor_token description. Only error/edge behavior is left unspecified.

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 coverage is only 33% (only actor_token is documented), so the description must compensate; it does so for the most consequential parameter by explaining that memo_text upgrades the result to substantive verification and that omitting it degrades to receipt_integrity only. receipt_id receives no semantic explanation, but its name and role in the description are self-evident.

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?

Names a specific verb and resource ('Check a memo receipt against the hash-chained docket') and even states the substance of the answer (what was allowed, why, from which labeled evidence). An agent can distinguish this from sibling verification tools like atlas.pulse_memo or atlas.pulse_use, though no sibling is named explicitly.

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?

Gives clear conditional usage: without memo_text you receive only receipt_integrity, and passing memo_text yields memo_verified / VERIFIED. This tells the agent exactly when to supply the optional argument. It does not, however, state when to prefer this tool over adjacent siblings such as atlas.pulse_memo or atlas.pulse_use.

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