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

The description transparently discloses key behavioral aspects: it produces a verifiable receipt, does not require secrets ('no secret'), does not make callbacks ('no request back'), and does not verify the truthfulness of statements. It also states that it 'records that you made it, when', which clarifies the data captured. While it does not mention persistence or potential side effects, the provided transparency is above average given no annotations exist.

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 concise and flows logically from action to output to use case. It avoids unnecessary details but includes a slightly poetic and redundant phrasing ('Coolant does not check...' repeats the earlier 'does not check') that could be tightened. Overall, it is well-structured and to the point, earning a 4.

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 simple tool, the description covers the essential context: input (statement), output (receipt), verification method (public key), and intended usage scenario. It does not discuss error conditions, expiration semantics, or verification steps in detail, but these are not critical for basic understanding. The description is sufficiently complete for an agent to invoke the tool correctly in most situations.

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 schema already covers both parameters with descriptions (statement and expires with type and constraints). The description adds minimal extra context: 'short statement' aligns with the 512-character limit, but it does not explain how 'expires' affects the attestation or provide examples. Since schema coverage is 100%, the baseline is 3, and the description does not meaningfully add to parameter understanding.

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 clearly states the tool's function: 'Witness a short statement at a time, and return a receipt anyone can verify with the public key at /.well-known/coolant.json'. It also explicitly distinguishes it from truth-checking ('does not check whether the statement is true') and provides a concrete use case ('Two agents use this to hold each other to something neither can later deny saying'). This makes the purpose unambiguous and easily distinguishable from sibling tools like notary or receipt.

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?

The description mentions a specific use case and two behavioral caveats ('no secret, no request back' and 'does not check whether the statement is true'), which help in deciding when to use the tool. However, it does not explicitly name alternative tools (e.g., notary, receipt) or provide criteria for choosing between them. The guidance is implied rather than explicit, earning a moderate score.

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