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

With no annotations, the description must carry the behavioral burden, and it does add one useful trait: the result attests to byte identity and is not an artistic review. It does not, however, explain what makes the subset 'safe', whether the operation is read-only, or what data is omitted.

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 description is only two short sentences and is front-loaded with the return action. The second sentence is cryptic but compact, and both sentences contribute meaning, so there is little waste.

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?

Although the output schema covers return values and there is only one parameter, the description leaves the core concept of a 'safe receipt subset' unexplained and gives no guidance on choosing this tool among its five siblings. An agent could call it, but would struggle to know what it will receive or why it is safe.

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?

The only parameter, job_id, already has a schema description ('FARPY job id.'), so schema coverage is 100%. The tool description adds no details about how job_id is validated or used beyond receiving the receipt, so the baseline of 3 is appropriate.

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 names an operation ('Return') and a resource ('safe receipt subset'), so it is not a tautology, but 'safe' and 'subset' are undefined domain jargon. The SHA-256 sentence hints at the receipt's role but does not clearly distinguish this from farpy_inspect or farpy_status.

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?

'SHA-256 is byte identity, not artistic review' implies this tool is for cryptographic/byte-level receipt verification rather than human quality review, which is an implicit when-not. However, it does not name sibling alternatives or state explicit conditions for choosing farpy_receipt over farpy_status or farpy_download.

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