Quotor — Home & Auto Insurance Quotes

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

Annotations provide readOnlyHint and openWorldHint. Description adds return values (quoting/binding availability, explanation) and auto-state behavior, adding context beyond annotations.

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?

Three concise sentences: purpose, usage, return summary. Front-loaded with key info, no wasted words.

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?

Simple tool with good annotations and full schema; description covers all essential aspects for an agent to correctly invoke it. Output schema exists, so return details are covered.

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%, so parameters are well-documented. Description adds value by noting that state is supplied automatically, explaining the absence of a state parameter, which is useful extra semantics.

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 clearly states it 'confirm[s] whether Libertas can quote and bind insurance for the customer in their state', with a specific verb and resource. It distinguishes from siblings by being the first call to make before personal details.

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?

Explicitly says 'Call this first — before collecting any personal details — when the customer asks about insurance prices, switching carriers, or shopping for coverage.' Also clarifies that state is auto-supplied, so no need to ask customer.

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

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

Annotations already indicate readOnlyHint=true and openWorldHint=true. The description adds substantial behavioral context: it pulls fresh reads, compares to original best, and uses a meaningful threshold ($100/yr or 5%). It also explains result handling with natural language narratives, providing transparency beyond annotations.

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 thorough but front-loaded with the core purpose. While longer, each sentence serves a clear role (purpose, prerequisites, exclusions, result handling). Slightly verbose but well-organized, making it effective for a complex decision tool.

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?

Given the output schema exists, the description adequately covers the boolean result and how to act on both true/false cases. It also addresses rate limits (2-turn cooldown) and linkage to customer state. The tool's conversational context is fully accounted for, making it complete for an AI agent.

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?

The sole parameter quote_id is well-described in the schema (100% coverage). The description adds context by tying the quote_id to the session that already has a baseline, reinforcing its purpose. This extra guidance justifies a score above baseline 3.

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 clearly states the tool's purpose as a 'save-the-sale' mechanism to check for late carrier rates when a customer shows dissatisfaction. It distinguishes itself from sibling tools like check_quote_status (initial quote status) and get_quote_options (showing options) by focusing on detecting improvements from previously slower carriers, using specific language like 'compares the current cheapest... to the original first-quoted best'.

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?

Provides explicit conditions for when to call (after check_quote_status returns 'quoted', customer expresses price resistance, not called in last 2 turns) and when not to call (customer is committing or hasn't seen initial options). This clearly guides the agent on appropriate invocation, differentiating from alternatives.

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

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

Even though annotations already provide readOnlyHint and openWorldHint, the description greatly expands on behavior: it explains the different states (running, quoted, timeout, needs_data, error), how each affects the workflow, and nuances like 'needs' riding along with 'quoted'. This goes well beyond the annotations.

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 relatively long but well-structured, with a clear initial statement followed by enumerated return statuses. Every sentence provides value, and the structure helps readability. It could be slightly more concise, but it earns its length.

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?

Given the complexity of the tool (multiple return statuses, integration with other tools like update_quote and get_quote_options), the description covers all necessary scenarios and provides complete guidance for handling each case. The presence of an output schema does not reduce the need for this thorough explanation.

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?

The input schema already describes both parameters with 100% coverage. The description does not add significant new information about the parameters beyond what the schema provides, so it meets the baseline but does not exceed it.

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 explicitly states the tool checks rating and live-finishing progress. It distinguishes itself from siblings like get_quote_options by specifying it is called between wait-phase questions and provides detailed return statuses, making its purpose very clear.

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 description gives explicit when-to-use guidance: 'Call between wait-phase questions (every customer turn or two after get_quote_options).' It also provides detailed instructions for each return status (e.g., how to handle 'needs_data' with update_quote), effectively guiding the agent on when and how to use the tool.

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

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

Annotations indicate readOnlyHint=false, destructiveHint=false, idempotentHint=false. Description adds important behavioral context: link is single-use, valid 7 days, reveals carrier name. No contradictions; description enriches understanding beyond annotations.

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?

Three sentences, each with distinct value: core purpose, alternative usage, and additional notes. Front-loaded and efficient; no wasted words.

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?

Given output schema exists, description covers all needed context: purpose, when to use, behavioral traits, and parameter examples. No gaps.

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 has 100% coverage with descriptions for both parameters. Description reinforces the purpose of quote_id and option_id, and gives a concrete example for option_id ('opt_home_a'). This adds marginal value beyond schema, justifying a 4.

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?

Description clearly states it generates a single-use secure link for bind hand-off. Explicitly distinguishes from request_bind_inline by specifying the alternative use case, making it clear what this tool does versus siblings.

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?

Provides explicit guidance on when to use get_bind_link: when customer wants to leave chat, finish on different device, or have numbers emailed. Mentions pairing with email offer, and contrasts with request_bind_inline for in-chat flow.

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

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

Annotations already declare readOnlyHint=true, indicating safe read operation. The description adds value by stating 'Carrier name remains masked' and enumerating the information returned (coverage breakdown, deductibles, etc.), which goes beyond annotations.

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?

Two sentences, zero fluff. The first sentence lists the output contents, the second provides usage guidance and a behavioral note. Every word earns its place.

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?

Given the presence of an output schema, the description appropriately avoids detailing return values. It covers purpose, usage context, and a key behavioral note (masking). Parameter examples are provided. No gaps remain for this tool.

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% with both parameters documented. The description adds an example for option_id ('e.g. 'opt_home_a' from get_quote_options'), which clarifies the expected format and relationship to a sibling tool, enhancing understanding beyond the schema alone.

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 clearly states it pulls detailed information for a single masked option, using specific terms like coverage breakdown, deductibles, discounts, and payment plan options. However, it does not explicitly differentiate from the sibling tool get_quote_options, which likely lists options; the context implies but does not state the distinction.

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 description explicitly says 'Use when the customer wants to dig into a specific quote before deciding,' providing clear context for when to invoke the tool. It does not mention when not to use it or contrast with alternatives, but the guidance is sufficient.

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

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

Annotations already indicate non-read-only and open world; description adds rich detail: immediate return, two-stage timing (30–90s first numbers, 2–10 minutes finishing), option range nature (indicative low end, final at or below), and hardening to verified. No contradictions.

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?

Description is relatively long but well-structured with line breaks and bold key phrases. Main action is front-loaded. Could be more concise, but information is efficiently organized.

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?

Given complexity, schema and output schema coverage, description fully covers the asynchronous process, stages, and how to check status via sibling tool. No gaps identified.

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%, so baseline is 3. Description does not elaborate on parameters beyond what schema provides, but context implies their roles. No additional semantic depth added.

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 clearly states the tool's core action: firing carriers in parallel and kicking off rate-finishing, returning immediately. It distinguishes from siblings like check_quote_status which reports on the process.

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?

Explicitly advises when to call (only if a rating-changing input changes) and what to do during the wait (conversation playbook). Also specifies not to re-fire for waters toggle, providing clear usage boundaries.

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

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

Beyond annotations, the description reveals that the tool triggers a licensed team task, is non-binding and reversible, and does not collect payment or start coverage.

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 well-structured with front-loaded purpose and clear caveats, but is slightly verbose with some repeated concepts.

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?

Given the tool's complexity and presence of output schema, the description covers all necessary context: asynchronous nature, non-binding, confirmation threshold, and naming constraints.

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%, so baseline is 3. The description does not add further parameter meaning, but schema descriptions are sufficient.

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 clearly states the verb 'Submit' and the resource 'customer's bind request', and differentiates from sibling tools like get_bind_link by specifying it triggers an internal task.

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 description explicitly tells when to use (customer's clear choice) and when not to use (not instant bind), and provides specific guidance on carrier naming and confirmation prompts.

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

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

Beyond annotations (readOnlyHint, openWorldHint), the description explains verification logic (same user vs. different user requiring code) and specifies return values: status, summary, rate option availability. No contradiction with annotations.

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?

Three sentences front-load purpose, then detail verification, then describe output. No redundant or unnecessary information; each sentence earns its place.

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?

Covers core functionality, verification scenarios, and return content. With an output schema present, the description does not need to detail exact return format. Minor gaps like error handling are acceptable given schema coverage and 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 100% with clear descriptions for both quote_id and verification. The description adds value by explaining the conditional nature of verification and the context of email codes, enhancing understanding beyond the schema.

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 clearly states the specific verb 'resume' (pick up) and the resource 'existing quote' with context of previous session or different platform. It distinguishes from siblings like start_quote and check_quote_status by focusing on continuation rather than creation or status check alone.

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 description implies usage context: when a user has an existing quote from a prior session or platform. It provides prerequisites (quote ID) and conditions (verification needed if different user). However, it does not explicitly name alternatives or say when not to use it, leaving some ambiguity against siblings.

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

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

Discloses that it returns a quote ID for subsequent calls. Provides an extensive, structured intake script detailing how to collect information. Annotations do not contradict; openWorldHint is reflected in flexible intake.

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 quite long with multiple paragraphs and a detailed ordered list. While informative, it is not concise; the first sentence is clear but the rest could be trimmed.

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?

Given the output schema exists, return values need not be explained. The description provides extensive context on the intake process, making it complete for an agent.

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 covers all 3 parameters with 100% description coverage. Description does not add significant new meaning beyond schema; baseline 3 is appropriate.

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 clearly states it begins a new quote for home, auto, or bundle, and returns a quote ID. It distinguishes from siblings like resume_quote and get_quote_options.

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?

Explicitly says 'Call this when the customer wants to get an insurance price.' Also provides a detailed intake order and instructs to call get_quote_options immediately after.

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

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

Annotations indicate readOnlyHint=false and openWorldHint=true, and the description explains the side effect (creates a row in CRM, triggers agent follow-up within one business day) without contradicting annotations. No destructive 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 long but well-structured: it starts with a summary, then uses bullet points for usage guidelines, and ends with additional details. Every sentence is relevant, though slightly verbose.

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?

Given the tool's complexity (9 parameters, output schema exists), the description covers prerequisites (contact info needed), return value (confirmation message), and follow-up timeline, making it fully actionable.

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% with descriptions for all 9 parameters. The description adds context beyond the schema, such as the purpose of 'interest' and that 'notes' are optional, but does not significantly expand on each parameter's meaning.

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 clearly states the tool captures leads for insurance products not quoted inline or when a customer requests follow-up, specifying the action (create CRM row) and resource (Leads bucket). It distinguishes from sibling tools like start_quote which handle inline quoting.

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?

Explicitly lists when to call (e.g., non-home/auto inquiries with contact info, customer asks for call later) and when not to call (active intake, missing contact info), providing clear context and exclusions.

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

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

Annotations provide idempotentHint=true, readOnlyHint=false, destructiveHint=false. The description adds context by stating idempotency, return fields (applied/rejected), and regulation details. It could mention error handling more explicitly, but overall adds value beyond annotations.

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 well-structured with sections and front-loaded purpose. While slightly lengthy, every section serves a purpose. Could be slightly more concise but maintains clarity.

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?

Given the tool's complexity (nested patch object, regulated fields) and presence of an output schema, the description is comprehensive, covering purpose, usage, parameters, and behavioral nuances adequately.

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%, providing baselines. However, the description significantly augments schema with detailed structure of the 'patch' parameter, examples, and references to an override matrix, making parameters much clearer.

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 clearly states the tool's purpose: 'Set or refine any quote parameter except regulated enrichment fields.' It specifies idempotent behavior, return values, and differentiates from siblings by detailing when to call it, such as after start_quote or when customers change their minds.

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 description includes an explicit 'WHEN TO CALL' section listing three distinct scenarios, and also notes that regulated fields will be rejected, providing clear guidance on appropriate usage versus alternatives like get_quote_options.

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