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

Annotations already declare non-read-only, idempotent, non-destructive and closed-world, but the description adds real behavior the annotations cannot convey: the receipt token is the requirement's token and is reused by request_status and offers, a re-send records a revision of the same request rather than a new one, and the call commits to nothing ("This orders nothing"). The privacy instruction for the token is useful operational context. It does not say what happens on a stale or mismatched revision, which is the remaining gap.

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?

Purpose is front-loaded, then behavior, then the non-ordering caveat — a sensible order with no filler sentences. The phrasing is compressed to the point of being slightly cryptic ("Name the revision the buyer saw"), but every sentence carries information.

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 non-idempotent-looking submission with a nested contact object and no output schema, the description covers the core state transitions well but never mentions contact (whose contact is being supplied?) or op_id, and gives no hint of what a successful send returns. Adequate, not complete.

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?

At 50% schema coverage, the description does compensate for two of the undocumented parameters: it explains the dual role of token (also the request's receipt token) and the meaning of revision (the one the buyer actually saw). However, contact and op_id are unexplained in both schema and description, so half the surface still relies on inference. Baseline 3 fits.

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?

States a specific verb and resource ("Send the requirement to Millsheet") and immediately splits the behavior into first send vs. later send of a changed requirement. It also carves out the boundary with the offer path ("an offer comes later and is accepted separately"), so an agent can distinguish it from accept_offer without opening either schema.

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 a clear triggering condition ("once the buyer says to") and a precondition on the payload ("Name the revision the buyer saw"). It does not name edit_requirement or explain when to edit an existing request instead of re-sending a changed one, so routing between mutation siblings is left partly implicit.

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