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

Annotations already declare this is a write operation that is non-idempotent and non-destructive. The description adds important behavioral context: the submitter must sign with their own ed25519 key, the format is at /v1/method, anyone may submit, and receipts are counted by distinct issuer.

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 four compact sentences with the core action front-loaded and no obvious filler. The signing and counting details are relevant and reasonably structured, though the phrase about countersign_stamp could be more tightly integrated.

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 write tool with no output schema and a nested receipt object, the description covers signing, format location, anti-domination counting, and the countersign option. It leaves subject_id undocumented and does not describe error or duplicate-submission behavior beyond the non-idempotent annotation.

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 33%, so the description must carry more weight. It clarifies that receipt is a signed v=1 object, that signing uses the submitter's ed25519 key, and that countersign_stamp records a Countersign verdict, but it never explains subject_id.

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 states a specific verb and resource: recording a receipt that a tool or agent did or failed to do a piece of work. It also distinguishes the countersign use case by naming the countersign_stamp input, though it does not explicitly contrast with the countersign_stamp sibling tool.

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?

It explains that anyone may submit and that receipts are counted by distinct issuer to prevent one source dominating, which gives context for use. However, it gives no explicit when-to-use or when-not-to-use guidance against related tools such as countersign_stamp or feedback_submit.

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