Get quotation

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

Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds beyond annotations by revealing the tool aggregates three underlying calls (Quotations.get, getLineItems, getInvoices) and conditionally includes invoices only 'if any' were generated. This gives useful context about the tool's data scope and behavior.

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?

The description is two sentences with no filler. The first sentence front-loads the core functionality (what is returned), and the second adds valuable implementation context. Both sentences earn their place, making this an appropriately concise and well-structured definition.

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 simple one-parameter read tool with comprehensive annotations and no output schema, the description covers the essential information: it returns a quote, its line items, and any related invoices. It lacks details on error behavior or response structure, but these are less critical given the tool's simplicity and annotation coverage.

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 0%, so the description must compensate for the single parameter, quotation_id. The description never mentions the parameter or explains how to use it (e.g., the ID of the quotation to fetch). While the name is self-explanatory, the description adds no additional meaning over the schema, which is a clear gap given the low coverage.

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: 'One quote with its line items and any invoices generated from it.' This clearly distinguishes it from sibling tools like list_quotations (plural) and get_invoice (invoice-specific), and the explicit mention of included line items and invoices makes the tool's scope immediately understandable.

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?

The phrase 'One quote' strongly implies this tool is for fetching a single quotation by ID, contrasting with list_quotations. The description offers clear context for when to use it, though it does not explicitly name alternatives or state conditions to avoid using it. This is a minor omission, so 4 is appropriate.

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