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

With no annotations, the description carries the full burden and does well: it discloses the 5000-character limit, per-service format rules (plain / JSON / 0x file hash), that the buyer reads the text, and the critical hash-consistency requirement with the on-chain step. It stops short of stating overwrite/idempotency semantics or what failure looks like on a hash mismatch.

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?

Front-loads the role and action, then constraints, with almost no filler despite being fairly dense. The 'SAME text' emphasis and format clause both earn their place; only the stringing together of clauses makes it slightly harder to scan.

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 3-param, no-annotation, no-output-schema tool embedded in a two-step on-chain flow, the description covers the essential mechanics an agent needs to call it correctly. The gaps (order ID semantics, resubmission behavior) are real but secondary.

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 coverage is 0%, so the description has to compensate. It richly documents 'text' (size cap, JSON validity, file-hash form) and labels 'token' as a wallet token, but says nothing about 'order' — presumably the order ID from shop_orders — leaving one of three required parameters uninterpretable.

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 delivery text for an accepted order) and immediately anchors it to a role (Seller) and a downstream sibling (prepare_board_deliver). This is clearly distinguishable from the many prepare_* tools in the sibling list.

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?

Explains the workflow position: call this first, then deliver the keccak256 hash on chain via prepare_board_deliver using the SAME text. The ordering constraint is explicit, but there is no guidance on when-not-to-call, what happens if the text was already submitted, or how corrections work.

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