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

Goes far beyond the annotations: free sample first, one-off payment by the person, no signup, async sampling, results emailed, capability must be stored privately, and that invalid input fails with HTTP 422 error.missing/error.invalid and is not clarified. Also discloses legal responsibility and prohibited data (passwords, cookies, session tokens).

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 purpose and the free-sample model, and nearly every sentence carries operational value. It is long and interleaves legal boilerplate with the calling workflow, which would be better grouped, but there is 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?

For a 16-parameter, 11-required, async submission tool with no output schema, it covers the verification handshake, async sampling, email delivery, error semantics and capability handling. It stops short of telling the agent what to do next (quote/order/fetch siblings) or what the response contains.

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 reinforces the required-field contract and tells the agent to derive search_keywords itself, which is actionable semantics beyond the schema. However it enumerates only 8 required fields and omits human_email, row_commitment and idempotency_key, which are also required 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?

States a specific verb and resource — 'Request public web data as rows' — plus a disambiguating condition ('when browsing it yourself is impractical'). It does not name any sibling (e.g., revise_requisition for changing an existing request), 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?

Gives clear process context: collect all fields before calling, generate search_keywords yourself, the person must verify email before the sample is shown. It never states when to use a sibling instead or what to do if the request must change later, so no explicit exclusions.

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