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

Annotations only declare it is a non-idempotent, open-world, non-read-only call; the description goes much further by explaining the review-and-forward flow, that suppliers reply to the user directly, and that 'nothing is sent automatically'. It also states the anti-hallucination auth requirement ('never invent an email'), which is exactly the extra behavioral context annotations cannot carry.

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 earning its place: purpose first, then preconditions, then parameter guidance, then downstream behavior. Nothing is repeated from the schema and the critical user-consent instruction is 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?

For a mutation tool with no output schema and 12 parameters, the description covers purpose, preconditions, the key identifiers, and the reply/delivery flow. It omits guidance on the remaining buyer-detail and compliance fields (nda, export_controlled, needed_by), though the schema itself describes several of them.

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 50%, so the description must help, and it does add real meaning for part_id/supplier_slug ('from earlier results'), buyer_email, and consent. However six parameters (quantity, buyer_name, buyer_company, buyer_country, part_id, supplier_slug) lack schema descriptions, and the description covers only two of those unknowns, leaving a genuine gap for a 12-parameter tool.

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 states a specific verb and resource ('Send a quote request'), names the intermediary (whobuildsit) and the recipients (suppliers who can make the part). An agent can distinguish this from sibling read tools like search_suppliers or get_part without opening a schema.

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 a clear precondition ('Before calling, ASK THE USER for their work email and explicit consent') and directs the agent to pass a part_id or supplier_slug from earlier results when available. It stops short of naming an alternative tool or a when-not condition, so it is strong context without explicit routing.

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