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

Annotations already declare readOnlyHint=false and destructiveHint=false, so the mutation/no-destruction profile is covered. The description adds real context beyond that: a human team handles it asynchronously, the reply arrives by email within one business day, and 'nothing is charged or ordered' reassures the agent no commercial commitment occurs. What it lacks is any mention of failure modes or what identifier, if any, is returned.

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, front-loaded with the action, followed by the precondition and the expected turnaround. Every sentence adds something an agent needs — none is filler or restatement of the title.

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 an eight-parameter, five-required tool with no output schema, the description supplies the essential behavioral picture: what is sent, who receives it, the response channel and timing, and that no charge occurs. The remaining gap is the undocumented optional parameters and the absence of any returned-identifier hint, which matters if a quote must later be fetched.

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 only 38%, so the schema does not carry the full burden. The description groups the inputs conceptually (design, quantity, customer contact) but leaves note, company and needed_by undocumented in both description and schema. That is three of eight parameters with no guidance on when to populate them.

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: send design, quantity and customer contact to Karved to obtain a quote and proof. An agent can distinguish this from get_quote (retrieval) and create_design (creation) by the stated outcome. It stops short of naming those siblings explicitly, so differentiation is inferred rather than declared.

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 an explicit precondition — 'Only call it after the customer agreed' — which is the key gating condition for a customer-facing quote request. It does not name an alternative for checking an existing quote (e.g. get_quote), so the when-not path is partial.

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