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

Annotations already declare readOnly/idempotent/non-destructive, and the description adds substantial context beyond them: the 25-250 cm per-side bounds, what quotation_price does and does not include (option costs live in notes), the >105 cm disassembled frame kit, and the 3-face portrait coverage. It also instructs the agent to hand order_page_url to the user, which is real behavioral guidance. Minor gap: no note on currency or unit-conversion behavior beyond the size bounds.

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 usage are front-loaded in the first two sentences, and later clauses about frames, sizing, and returns all carry information. It is dense and parenthetical, though, and the frame_code enumeration largely duplicates the already-verbose schema description, which costs some efficiency.

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?

With no output schema, the description carries the return contract itself and does so thoroughly, listing quotation_price, currency, frame fields, dimensions, notes, and order_page_url. Combined with the sizing limits and fallback conditions, an agent has everything needed to call it and to communicate the result.

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 100% and the frame_code property description is already exhaustive, so much of the frame_code and senior_artist wording is restated. The description still earns credit for adding semantics absent from the schema, notably the 25-250 cm per-side limit (schema only enforces exclusiveMinimum 0) and the fact that frame_code/senior_artist prices are folded into quotation_price.

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 opening sentence states a specific verb (price quotation) and resource (a CUSTOM reproduction from a customer-supplied image), and immediately scopes it against the catalog path by declaring 'No artwork identification is needed or accepted'. An agent can distinguish this from get_a_quotation without opening either 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 names the exact triggers for this tool: search tools returning nothing relevant, get_a_quotation failing with artwork_not_found, or the customer wanting their own picture reproduced. The fallback relationship to the sibling tool is explicit rather than inferred.

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