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

With no annotations, the description does most of the behavioral disclosure: the receipt is public and append-only, optionally tied to the caller's ed25519 key, and requires no account. It leaves minor gaps such as exact receipt format and error behavior, but the key side effects are disclosed.

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?

Four short sentences, each carrying distinct information: purpose, mechanics, optional identity binding, and cost/account posture. It is front-loaded with the use case and contains no filler.

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 one-required-parameter tool with no output schema, the description covers what to send, what to expect back, and where the record lives. It stops short of spelling out the receipt's structure or failure modes, but those are not essential for selecting and invoking the tool.

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 describes all three parameters (100% coverage), but the description adds value: it says the hash can be of 'any bytes' and explains that the optional signature/public key are used to 'tie the receipt to you'. That interpretation is not present in the schema.

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 a concrete action ('stamp'), the exact input ('sha256 of any bytes'), and the result ('signed, dated receipt held in a public append-only ledger'). It does not explicitly compare itself to sibling tools, but the witnessed-timestamping domain is distinct.

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 gives a clear usage scenario ('what you knew before you acted') and adds practical context ('Free, no account'). However it never names alternative tools or states when not to use witness_stamp, so the agent must infer differentiation from sibling names.

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