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

Annotations already declare destructiveHint=true and openWorldHint=true. The description goes beyond them with genuinely useful facts: quotas are shared with the WebAZ page, auto_accept is stored but inactive, source_link is private and never fetched, and publish requires expected_version + summary_digest (optimistic concurrency). However, it does not warn about the consequences of the destructive 'close' action or what publish irreversibly exposes, which is the main behavioral risk an agent needs flagged.

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 resource and the trigger, then compresses the workflow into an arrow chain with no filler. Every clause carries information (quota sharing, stored-only auto_accept, private source_link). The telegraphic style ('→ get → read summary', '→ changes') is terse to the point of ambiguity in places, but it is appropriately sized for a 22-parameter, 7-action tool.

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 destructive, open-world, multi-action tool with no output schema, the description covers only the create/publish happy path. It says nothing about what list/get/revise/close/changes return or require, nothing about pagination via after/limit, and nothing about error or version-conflict handling. Adequate for the headline flow, incomplete for the tool as defined.

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 only 36% across 22 parameters, so the description must compensate. It does add real meaning for the highest-risk fields — source_link, auto_accept, expected_version, summary_digest — but leaves most parameters (title, category, required, preferences, budget, urgency, game_currency, after/limit pagination) undocumented in both places. Partial compensation, not full.

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?

Opens with a concrete resource identity ('Find-it-for-me requests (buyer)') and a specific verb chain (create → get → publish → changes). It explicitly names the sibling it substitutes for ('use when webaz_search finds nothing'), so an agent can distinguish it. The only gap is that the seven action values (list, revise, close, etc.) are never described, so the tool's full surface is only partly visible.

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 an explicit trigger condition ('Use when webaz_search finds nothing') plus an ordered operational sequence with the human-in-the-loop step ('read summary to the user'). It also warns 'never invent requirements', a real constraint on behavior. No explicit when-not beyond the search fallback, and no guidance on when to use revise/close versus creating a new request.

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