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

Annotations already establish non-read-only, idempotent, non-destructive behavior. The description adds meaningful beyond-annotation context: the operation is asynchronous, returns an operation ID, the quote bounds spending, and the search carries rights scope/input. The explicit 'Submission is distinct from removal' further clarifies the tool's side effects.

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?

Four sentences, each carrying distinct information: operation type, quote bounds, return mechanism, and distinction from removal. There is little waste, though the final sentence is somewhat cryptic and could be clearer. Overall it is efficiently front-loaded.

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?

The description covers the return value and how to obtain results (poll get_operation), which is important given there is no output schema. But it omits prerequisites (how a quote is obtained and approved), the meaning of idempotency_key, and potential error scenarios. For a two-parameter async tool, it is adequate but 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?

Schema description coverage is 0%, so the description must compensate, but it does not explicitly explain either parameter. It refers generally to 'quote' which loosely maps to quote_id, but idempotency_key is never addressed. An agent would have to infer that quote_id identifies the pre-approved quote and that idempotency_key supports idempotent retries. Minimal value is added over the bare 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?

The description uses a specific verb and resource: 'Execute a pre-approved search quote asynchronously.' This clearly distinguishes the tool from siblings like create_quote (which creates the quote) and submit_takedown (which handles removal). The final sentence, 'Submission is distinct from removal,' further differentiates it from takedown workflows.

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?

The description gives clear context for when to use the tool: after a quote is pre-approved, and it instructs the caller to 'poll get_operation' for results. It also warns that submission is not removal, providing a useful exclusionary signal. However, it does not explicitly name alternative tools (e.g., create_quote to obtain a quote) or spell out the full workflow.

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