get_quote_requirementsReturns the exact details to collect from the customer for a line of insurance — the same rating inputs MIB's own quote forms use. Call this FIRST, ask the customer the questions, then call compare_insurance_quotes with their answers. Omit product_type to see every line.
| Name | Required | Description | Default |
|---|---|---|---|
| product_type | No | The line of insurance. Omit to get the requirements for all lines. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Although no annotations are provided, the description fully explains the tool's behavior—it returns details and implies a read-only operation with no side effects, and even outlines the workflow with the subsequent tool.
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 concise, well-structured, and includes purpose, usage order, and parameter handling in two sentences without unnecessary fluff.
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?
The description is self-contained and provides sufficient context for an agent to understand when and how to use the tool, including its relationship to compare_insurance_quotes, without needing additional 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 single parameter product_type is fully described in the schema with an enum and explanation of omission, and the description reinforces this, covering all parameter nuances.
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 returns details to collect from the customer for a line of insurance, distinguishing it from sibling tools like compare_insurance_quotes and list_insurance_products.
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 instructs to call first and then use the output with compare_insurance_quotes, and explains the effect of omitting product_type, providing clear when-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
Each tool has a distinct purpose: about_mib_for_developers is informational, compare_insurance_quotes and policy_checkup differ (new vs existing policies), get_quote_requirements provides inputs, get_buy_link generates purchase links, and list_insurance_products browses catalogs. No two tools overlap ambiguously.
Most tools follow a verb_noun pattern (compare, get, list, about), but policy_checkup is noun_verb, and about_mib_for_developers is more descriptive. Minor inconsistency but still readable and predictable.
With 6 tools, the server is well-scoped for insurance comparison and purchase. Each tool fills a necessary role without redundancy or bloat, fitting the typical 3-15 tool range.
The toolset covers the full workflow: requirements gathering, quote comparison, purchase link generation, product browsing, and existing policy analysis. No obvious missing operations for its stated purpose.