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

Beyond the annotations (openWorldHint=true, non-idempotent, non-destructive), it discloses the full downstream consequence: Rich replies by email within one business day with a price and payment link, the person pays in a browser, and nothing is charged here. For an outward-facing side-effecting tool this is exactly the context an agent needs to set expectations and avoid implying an in-tool purchase.

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?

Purpose and the permission constraint are front-loaded, and every sentence carries information (recipient, constraint, outcome, required inputs, file options). The final sentence is long and runs multiple clauses together, slightly hurting scannability.

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 9-parameter, non-idempotent, open-world submission tool with no output schema, the description covers prerequisites, expected inputs, accepted file forms, and the offline follow-up path. The only gap is that it never says what the tool itself returns to the agent (e.g., a confirmation or reference), which matters slightly given the absence of an output schema.

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 already 89%, but the description adds real meaning beyond it: a file is optional, accepted formats are STL/OBJ/3MF/STEP or Printables/Thingiverse/MakerWorld links, and with no file the agent should supply measurements because design and printing are quoted together. That materially guides file_url, description, and wants beyond the schema definitions.

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 first sentence names a specific verb and resource ('Send a quote request ... for a person who wants something 3D printed or designed') and identifies the recipient and channel. An agent can immediately distinguish this from sibling tools like print_price_examples or search_products, though explicit routing against quote_custom_print is left to the file_key parameter text.

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 states a hard prerequisite ('Only with the person's permission, and only with their own name and email') and tells the agent what information to gather (what it is, size, material/color, quantity, deadline). What's missing is explicit guidance on when to pick this versus quote_custom_print or create_checkout, so there is context but no alternatives or exclusions.

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