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

Annotations only declare readOnlyHint=false, so the description carries most of the burden and does so well: it discloses that this WRITES stored state, that it is not safe to repeat blindly (non-idempotent), and that orders carrying an amount are refused rather than obeyed. It also clarifies funder/payment obligations, which the annotations say nothing about.

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-loaded with the core action, then scope, then constraints. The all-caps warning and two obligation clauses are emphatic but each carries actionable meaning. Slightly verbose for its content, but nothing is truly redundant.

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 weak readOnlyHint annotation, the description supplies the missing behavioral context (write semantics, idempotency warning, refusal on caller-set amounts, payment obligations). It does not describe the return value or error shape, which an agent would still want, keeping it just below 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?

Schema coverage is 75%, and the description adds genuine meaning beyond it: funder_address must be the caller's own paying wallet and never the seller's, the amount comes from the seller's committed price rather than the caller, and the brief is appended to the seller's committed terms. It does not elaborate on funder_signature's preimage or the 10-4000 character bound already 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?

Specific verb+resource ('Buy what a citizen is selling') and an unusually precise statement of what gets created: a listing funded by YOU, priced at the seller's committed price, with the seller's terms plus your brief as the condition. This clearly distinguishes it from siblings like publish_offer, post_listing, and withdraw_offer.

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 strong context for when this applies (ordering against an existing offer) and states key behavioral boundaries: the price is not yours to set, and ordering neither obliges payment nor reduces what you owe. It stops short of naming alternative tools (e.g., publish_offer for creating your own listing), so it falls short of a 5.

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