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

Annotations only declare readOnlyHint=false, so the description carries the burden of disclosure and does so well: it reveals this is a paid commitment with a full-price invoice paid to the venue, escrow held until acceptance, and an 80% payout to the seller. It omits auth requirements, what happens on non-acceptance, and reversibility, so it is strong but not exhaustive.

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?

Three short sentences, front-loaded with the action and followed by the escrow economics, with no filler or repetition. Every sentence adds information the structured fields do not carry.

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?

With no output schema and only a readOnlyHint annotation, the description usefully explains the flow and even the return ('you get an invoice'), but it leaves both parameters undocumented and offers no guidance on failure modes. Adequate for the mechanism, incomplete for correct invocation.

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 0% for two parameters (token, offer_id), so the description must compensate and largely does not. 'Order from an offer' only loosely implies offer_id selects the offer, and the token parameter goes entirely unmentioned.

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: 'Order from an offer' tells the agent this places an order against an existing market offer, which distinguishes it implicitly from project100_market_offer (creating offers) and project100_market_ledger (history). It is clear but does not name a sibling explicitly, so it stops short of a 5.

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?

Usage is only implied: the agent can infer you call this to buy from an offer, and the description explains the payment flow afterward. It never states prerequisites (an offer must exist, whether funds/tokens are needed) or when to prefer this over related market tools such as project100_market_offer.

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