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

Beyond the annotations, the description discloses critical behavioral constraints: it uses buyer-supplied information only, performs no outbound actions, returns a draft for human review, and requires payment authorization. This substantially enriches the agent's understanding of what the tool will and won't do, and it does not directly contradict the annotations.

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 short sentences, each carrying distinct information: purpose, input constraints, output type, and pricing/payment. It is front-loaded with the core purpose and contains no filler.

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 states the output is a draft for human review and gives pricing/payment context, which covers the primary invocation. However, with no output schema and no explanation of the result_expires/result_signature/payment_signature protocol parameters, an agent cannot fully anticipate the request flow or result structure.

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?

With 0% schema description coverage, the description was expected to compensate, but it never names or explains the parameters. It only vaguely references the 'supplied offer' (likely source_text) and payment authorization (payment_signature), leaving result_expires, idempotency_key, and result_signature semantically unexplained.

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 opens with a specific verb and object—'Design a pricing research process and experiments from the supplied offer'—and explicitly distinguishes itself from actual market research by saying 'do not claim market prices were researched.' This clearly sets it apart from siblings that produce research findings or reports.

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?

It gives clear context: use this when the buyer has supplied an offer and wants a research plan, not executed research. The exclusions are explicit ('no external research or outbound actions'), though no sibling tool is named as an alternative, so the guidance stops short of fully explicit routing.

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