Quotor — Home & Auto Insurance Quotes
Server Details
Real, bindable home & auto insurance quotes via MCP (Texas, expanding); human-completed bind.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 4.5/5 across 11 of 11 tools scored.
Each tool targets a distinct stage or action in the insurance quoting workflow. For instance, check_eligibility is for initial eligibility, check_late_arrivals handles late-arriving better rates, and get_quote_options fires quotes. There is no functional overlap between tools.
All tool names follow a consistent verb_noun pattern (e.g., check_eligibility, get_quote_options, resume_quote) using snake_case. No mixed conventions or inconsistent verb styles.
With 11 tools, the set is well-scoped for a comprehensive insurance quoting assistant. Each tool serves a necessary purpose without redundancy, covering the entire flow from start to bind and handling edge cases.
The tool surface covers the core lifecycle: eligibility check, quote creation/update, option retrieval, status monitoring, bind (two methods), and lead submission for non-covered products. Minor gaps exist (e.g., no explicit side-by-side comparison, no cancel/decline tool), but these are manageable via conversation.
Available Tools
11 toolscheck_eligibilityARead-onlyInspect
Confirm whether Libertas can quote and bind insurance for the customer in their state. Call this first — before collecting any personal details — when the customer asks about insurance prices, switching carriers, or shopping for coverage. State is supplied automatically from the request context (the platform's location consent flow); you don't need to ask the customer for state to call this. Returns whether quoting is available, whether binding is available, and a plain-language explanation the customer can read.
| Name | Required | Description | Default |
|---|---|---|---|
| intent | No | Whether you're checking ability to 'quote' or to 'bind' (default 'quote'). | quote |
| product | Yes | Line of business: 'auto', 'home', or 'bundle' (home + auto). |
Output Schema
| Name | Required | Description |
|---|---|---|
| state | No | |
| can_bind | No | |
| can_quote | No | |
| next_step | No | |
| explanation | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint and openWorldHint. The description adds value by explaining the tool returns availability for quoting and binding plus a plain-language explanation. 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?
Four sentences, each earning its place: purpose, usage order, state automation, return value summary. Front-loaded with the core action.
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 (not shown in text but indicated), the description sufficiently covers when to use, what it returns, and handles the implicit state parameter. A complete description for a two-parameter readonly 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 clear enums and descriptions for both parameters (intent, product). The description does not add parameter-level details beyond the schema, but it does contextualize that state is implicit, meeting the baseline expectation.
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 confirms eligibility to quote and bind insurance. It specifies the resource ('Libertas'), action ('confirm'), and context ('in their state'), distinguishing it from sibling tools like 'start_quote' or 'get_quote_options' which assume eligibility is already checked.
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?
Explicit instructions are given: 'Call this first — before collecting any personal details' and specific scenarios (customer asks about prices, switching carriers, shopping). It clarifies that state is supplied automatically, so the agent should not ask the customer for it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
check_late_arrivalsARead-onlyInspect
Save-the-sale tool — call when the customer signals dissatisfaction with the current options ("too expensive", "let me think", "what else do you have", "is this the best you can do", "I'll check elsewhere", "can you do better"). Some carriers (Foremost STAR, etc.) run slower than the initial set and may have come back with a better rate while the customer was deliberating. This tool:
Pulls a fresh read of all rated carriers.
Compares the current cheapest bundle/LOB price to the original first-quoted best.
Returns has_improvement=true ONLY if a late carrier beats the original by >= $100/yr OR >= 5% — a threshold meaningful enough to justify interrupting the customer.
CALL THIS ONLY WHEN:
check_quote_status has returned 'quoted' at least once (there's a baseline to compare).
The customer just expressed price resistance or hesitation (not a closed positive).
You have NOT called check_late_arrivals in the last 2 turns (don't spam).
DO NOT CALL WHEN:
The customer is actively committing ("yeah let's go with A") — that's a close moment, not a wavering moment.
The customer hasn't seen the initial options yet.
WHAT TO DO WITH THE RESULT:
has_improvement=true → narrate the improvement naturally ("Quick update — one more carrier just came in $X/yr cheaper. Want me to refresh your options?") and the iframe auto-updates with the new state.
has_improvement=false → acknowledge the customer's concern, pivot to value positioning against the options on the table. Don't bluff a "better one is coming" if it isn't. Use the carriers_still_pending count if relevant ("a couple more carriers are still finalizing in the background — I'll flag if anything comes in lower").
| Name | Required | Description | Default |
|---|---|---|---|
| quote_id | Yes | The quote session id to check for late-arriving carrier rates. |
Output Schema
| Name | Required | Description |
|---|---|---|
| new_options | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description details that the tool pulls fresh reads, compares prices, and returns has_improvement only if a threshold is met. It also explains what to do with the result, aligning with annotations (readOnlyHint, openWorldHint). 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?
The description is well-structured with bullet points and clear sections, but it is relatively long. Each sentence adds value, though some minor redundancy 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 complexity of the tool (late arrivals, threshold, usage guidelines, and output handling), the description is comprehensive. It covers when, why, and how to use the tool, and what to do with results, 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 coverage is 100% with clear description for the single parameter (quote_id). The tool description does not add further semantics beyond the schema, so 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 the tool is a 'save-the-sale' tool to check for late carrier rates when a customer expresses dissatisfaction. It specifies the verb ('check for late carrier rates') and resource, effectively distinguishing it from siblings like check_quote_status 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 lists when to call (after quote is 'quoted', customer expresses price resistance), when not to call (customer committing, not seen options), and provides a threshold for improvement. Also warns against spamming by limiting to once per 2 turns.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
check_quote_statusARead-onlyInspect
Check rating + live-finishing progress. Call between wait-phase questions (every customer turn or two after get_quote_options). Returns one of:
'running' — indicatives still landing; continue the wait-phase conversation, call again next turn.
'quoted' — options[] is populated. CHECK THE 'finishing' BLOCK: when finishing.active=true, the exact bindable rates are STILL being captured live at the carrier portals — present the price ranges confidently as honest estimates (the low end is the carrier's own starting figure; NEVER promise the final number can't exceed the range), keep the conversation going, and keep checking on later turns; cards harden to 'verified' automatically as walks complete. When finishing.active=false, the run is over: cards marked 'verified' are exact bindable numbers; anything still 'estimate' stays a range that a licensed agent confirms at bind.
'timeout' — carriers took too long; offer to retry with get_quote_options.
'error' — all carriers errored; flag it honestly and offer to retry. Each option carries rate_state ('verified' | 'verifying' | 'estimate') and, for unverified options, price_range {low, high}. NEVER mention carrier counts or real carrier names in chat.
| Name | Required | Description | Default |
|---|---|---|---|
| quote_id | Yes | The quote session id to poll. | |
| max_options | No | Maximum options to return per line (1-5, default 3). |
Output Schema
| Name | Required | Description |
|---|---|---|
| status | No | |
| options | No | |
| quote_id | No | |
| progress_pct | No | |
| carrier_names_revealed | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description extensively discloses behavior beyond annotations: it explains the meaning of each status ('running', 'quoted', 'timeout', 'error'), how to handle the 'finishing' block, and provides guidelines for customer-facing language (e.g., never promise final numbers). Annotations already declare readOnlyHint and openWorldHint, and the description adds rich operational context without contradiction.
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 fairly long but well-structured with bullet points for different statuses. It includes necessary details without being overly verbose, though it could be slightly more streamlined. Every sentence serves a purpose, but the length might be marginally high for a simple polling 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 complexity of polling with multiple states and the need for precise instructions on handling each, the description is remarkably complete. It covers all statuses, provides actionable advice (e.g., 'keep checking on later turns'), and even includes warnings about carrier names. The presence of an output schema (not shown) further reduces the burden on the description.
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 100% (both 'quote_id' and 'max_options' are described). The description adds minimal value beyond the schema, only clarifying that 'max_options' applies per line. With high coverage, the baseline 3 is appropriate; the description does not significantly enhance parameter understanding.
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: 'Check rating + live-finishing progress.' It specifies the exact use case between wait-phase questions and distinguishes it from siblings by focusing on status polling rather than initial quoting or other operations.
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 provides explicit guidance: 'Call between wait-phase questions (every customer turn or two after get_quote_options).' It also details when to call again based on the returned status. However, it does not explicitly state when not to use it or mention alternatives, leaving room for slight ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_bind_linkAInspect
Generate a single-use secure link, valid for 7 days, that the customer can follow to a Libertas bind-request page. The chat widget will usually render an inline 'Request Bind' card directly — prefer request_bind_inline for the in-chat flow. Use get_bind_link when the customer wants to leave the chat, finish on a different device, or have their final numbers emailed to them (pair it with the email offer during a long finishing wait). The bind link reveals the real carrier name (the only place it's revealed).
| Name | Required | Description | Default |
|---|---|---|---|
| quote_id | Yes | The quote session id. | |
| option_id | Yes | The option the customer chose to bind, e.g. 'opt_home_a'. |
Output Schema
| Name | Required | Description |
|---|---|---|
| bind_url | No | |
| quote_id | No | |
| option_id | No | |
| expires_at | No | |
| carrier_name | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Describes link as single-use and valid for 7 days, and notes it reveals carrier name. No contradiction with annotations. Adds useful behavioral 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?
Four sentences, each adding value: purpose, usage guidance, alternative scenarios, and behavioral detail. No redundancy.
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?
Completeness is high given output schema exists. Covers purpose, usage, and behavior. Could mention prerequisites or error handling, but sufficient for agent decision.
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 description does not add new information about parameters beyond what schema already provides. Baseline score.
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 generates a single-use secure link for a bind-request page, specifies the action and resource, and distinguishes it from sibling tool request_bind_inline.
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 states when to use this tool vs request_bind_inline, including scenarios like leaving chat or using different device, and suggests pairing with email offer.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_option_detailsARead-onlyInspect
Pull the full coverage breakdown, deductibles, applied discounts, and payment plan options for a single masked option (Home Carrier A, Auto Carrier B, etc.). Use when the customer wants to dig into a specific quote before deciding. Carrier name remains masked.
| Name | Required | Description | Default |
|---|---|---|---|
| quote_id | Yes | The quote session id. | |
| option_id | Yes | The option to detail, e.g. 'opt_home_a' from get_quote_options. |
Output Schema
| Name | Required | Description |
|---|---|---|
| coverages | No | |
| premium_annual | No | |
| premium_monthly | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark it as read-only. The description adds value by specifying what is pulled (coverage, deductibles, discounts, payment plans) and that carrier names remain masked, without contradicting 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 concise sentences with no wasted words. The first sentence lists the data pulled, the second adds usage guidance and a behavioral note. Front-loaded and efficient.
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 only two parameters, a read-only annotation, and an output schema, the description covers the purpose, return details, usage scenario, and key behavioral trait (masking). Complete for the tool's complexity.
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 parameter descriptions. The description reinforces the option_id parameter with examples (e.g., 'opt_home_a') but adds little new beyond the schema. Baseline score 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 the tool pulls 'full coverage breakdown, deductibles, applied discounts, and payment plan options' for a single masked option, distinguishing it from sibling tools like get_quote_options which list 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?
It advises use 'when the customer wants to dig into a specific quote before deciding', providing clear context. It does not explicitly state alternatives or when not to use, but the sibling tool get_quote_options is implied as the preceding step.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_quote_optionsAInspect
Fire all eligible A-rated carriers in parallel AND kick off live rate-finishing. RETURNS IMMEDIATELY — does NOT wait.
TWO STAGES follow:
First numbers land in 30–90 seconds. Options surface as honest price RANGES — the low end is the carrier's indicative, so the final verified rate usually lands AT OR BELOW the low end.
The system keeps working for 2–10 minutes after that, logging into carrier portals and walking each competitive quote to its exact bindable rate. Option cards harden from "estimated range" to "verified" as each carrier completes. check_quote_status reports this via its 'finishing' block.
What you do during the wait: KEEP THE CONVERSATION GOING with the wait-phase playbook in the system prompt (waters first, then current premium — top priority — then claims color, pets, pool, start date, payment preference). Narrate the real finishing work honestly in ONE short line when relevant; never quantify carriers or name them.
Call get_quote_options again ONLY if a rating-changing input changes (waters toggle locally — never re-fire for those).
| Name | Required | Description | Default |
|---|---|---|---|
| quote_id | Yes | The quote session id returned by start_quote. | |
| max_options | No | Maximum options to return per line (1-5, default 3). |
Output Schema
| Name | Required | Description |
|---|---|---|
| status | No | |
| message | No | |
| quote_id | No | |
| expected_seconds | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description reveals key behavioral traits not in annotations: the tool is not idempotent (implied by only re-firing on changes), it fires carriers in parallel, returns immediately, and has a two-stage process with timing details. It also explains the nature of returned data (price ranges vs. verified rates). No contradiction with annotations (readOnlyHint false, idempotentHint false).
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 explicit sections and bullet points, making it easy to parse. It is somewhat verbose but every sentence adds value. It is front-loaded with the primary action and immediate return behavior.
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, the description covers all necessary aspects: what it does, when to call, what to expect, and how to handle the wait. It also references an output schema (present) but does not need to detail return values. The guidance on re-firing and the wait-phase playbook make it complete.
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 the description need not add much. It does not elaborate on 'quote_id' or 'max_options' beyond the schema, but the schema itself is clear. The description adds context about max_options default and max value, but that is already present in 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 tool's action: 'Fire all eligible A-rated carriers in parallel AND kick off live rate-finishing.' It distinguishes itself from siblings like 'check_quote_status' by explaining that this tool initiates the process and returns immediately, while others handle status or specific 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?
The description explicitly states when to use the tool ('Call get_quote_options again ONLY if a rating-changing input changes') and when not to ('waters toggle locally — never re-fire for those'). It also provides a wait-phase playbook and references sibling tool 'check_quote_status' for monitoring progress.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
request_bind_inlineAInspect
Submit the customer's bind request from the chat. Triggers an internal task for our licensed team to follow up. THIS IS NOT INSTANT BIND — coverage starts only after underwriting verification, payment capture, and carrier confirmation. Call this the MOMENT the customer says any variant of "I'd like to go with [Carrier X]" / "let's do A and A" / "I'll take Carrier B". DO NOT ask another confirmation question first ("All good?", "Want me to send the request?", "Shall I submit?") — those redundant check-ins kill sales. Their commit IS the trigger. NEVER name a real carrier in chat output — stay in "Carrier A/B/C" labels.
| Name | Required | Description | Default |
|---|---|---|---|
| pay_plan | No | Pay plan: 'monthly_eft' or 'pay_in_full' (required when an auto line is included). | |
| quote_id | Yes | The quote session id. | |
| best_time | No | Best time to reach the customer, e.g. 'weekday afternoons'. | |
| option_id | No | The single option to bind (or use option_ids for a bundle/split). | |
| option_ids | No | Multi-option bind. Either option_id or option_ids must be provided. | |
| contact_pref | No | How the customer prefers to be reached: 'call', 'text', or 'email'. | |
| customer_notes | No | Optional free-text notes from the customer for the agent. | |
| water_selections | No | Customer-selected water-coverage add-ons for home options (service line, water seepage, foundation water, sewer backup); the agent configures these at the carrier portal at bind. |
Output Schema
| Name | Required | Description |
|---|---|---|
| bind_url | No | |
| quote_id | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses that coverage is not instant, requires underwriting and payment verification. Annotations show readOnlyHint=false, destructiveHint=false, which are consistent. No contradiction.
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?
All sentences are valuable, but the description is slightly verbose. It is front-loaded with the primary action and key warnings.
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 8 parameters with 100% schema coverage, an output schema exists, and the description explains when to use and what happens after invocation, it is fully complete.
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 100%, so the baseline is 3. The description adds no extra semantics beyond what's in the schema, but the overall usage context compensates.
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 submits a bind request from chat and triggers an internal task. It explicitly distinguishes from instant bind, and the verb 'submit' combined with 'bind request' makes the action specific.
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 trigger phrases ('I'd like to go with...'), warns against redundant confirmations, and tells when NOT to call (not for instant binding). Also advises to use carrier labels (A/B/C) instead of real names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
resume_quoteARead-onlyInspect
Pick up an existing quote that was started in a previous session or on a different platform. The customer supplies a quote ID. Verification: if the same authenticated user (OAuth user_id matches across sessions), no extra verification is needed; otherwise the customer needs to provide an email code that was sent at quote start. Returns the current status, a summary of what's collected so far, and whether rate options are already available to review.
| Name | Required | Description | Default |
|---|---|---|---|
| quote_id | Yes | The quote session id to resume. | |
| verification | No | Ownership verification (email code, platform identity, or magic link); required to return PII. |
Output Schema
| Name | Required | Description |
|---|---|---|
| status | No | |
| quote_id | No | |
| verification_required | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only indicate readOnlyHint true and openWorldHint true. Description adds verification requirements and return value details (status, summary, rate availability), providing useful behavioral 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?
Four well-structured sentences, front-loaded with purpose, no fluff. Efficient and clear.
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 adequately covers verification scenarios and return details. Distinguishes from sibling tools like 'check_quote_status' and 'start_quote'.
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 adds value by explaining verification conditions (email code when user mismatch) and what 'quote_id' refers to, which supplements schema descriptions.
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 'Pick up an existing quote', specifying verb and resource. Distinguishes from sibling 'start_quote' which creates new sessions.
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 context for use (previous session, different platform) and verification logic. Could be improved by explicitly listing when not to use (e.g., if quote does not exist) and comparing to other tools like 'check_quote_status'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
start_quoteAInspect
Begin a new home, auto, or bundled insurance quote. Returns a quote ID to use on every following call. Call this when the customer wants to get an insurance price.
INTAKE ORDER (Kyle 2026-06-11 — collect in this order, ONE coherent chunk per turn):
HOME/BUNDLE: full name + date of birth for EVERYONE on the policy (relationship for non-PNI).
Address of the home + "is this a new purchase, or one you've owned a while?" (new purchase → ALSO capture current_address — where they live today; property.address stays the home being bought). Then mortgage + escrow + "roughly how old is the roof? — 'I don't know' is a fine answer" ride along (roof unknown → move on, never probe; roof REPLACED → one follow-up: hail-resistant / Class 1–4? → property.hail_resistant_roof + property.ul_impact_type). The home address doubles as auto garaging unless the cars live elsewhere.
AUTO/BUNDLE: year/make/model of every vehicle.
Any drivers NOT already named in step 1 — names + DOBs + relationship.
Email + phone, framed as "where should I send your final numbers?" — the consent line is REQUIRED on this turn.
ONE open question before firing: "Any coverages you want to tell me about before I run it?" Capture whatever they volunteer via update_quote and move on — do NOT turn this into a coverage consultation. Scheduled valuables (jewelry, art, guns, collections) are a POST-BIND follow-up: record them under the follow_ups patch branch and tell the customer "our team will add that right after we get this policy locked" — never try to add them mid-quote.
Then call get_quote_options immediately. Don't over-collect — the customer should reach prices fast.
| Name | Required | Description | Default |
|---|---|---|---|
| product | Yes | Line of business to quote: 'auto', 'home', or 'bundle'. | |
| meta_codes | No | Optional internal meta codes; ignored unless recognized. | |
| referral_source | No | Optional referral/partner source tag for attribution. |
Output Schema
| Name | Required | Description |
|---|---|---|
| quote_id | No | |
| session_expires_at | No | |
| next_required_inputs | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide readOnlyHint=false, openWorldHint=true, etc. The description adds significant behavioral context: it returns a quote ID used in subsequent calls, specifies the exact steps to follow after starting (including calling get_quote_options immediately), and details the intake order. No contradictions 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?
The description is verbose with multiple paragraphs and very detailed procedural steps. While structured with numbered steps and clear sections, it is not concise. The first sentence is good, but the rest adds substantial length that could be distilled.
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 (3 parameters, output schema exists, annotations present), the description is highly complete. It covers the entire workflow, including the intake order, next steps, and what to avoid. It even includes a version date. A minor deduction for not explicitly mentioning the output schema but it is implied.
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 100% with clear descriptions for all three parameters. The description does not add meaning beyond the schema for parameters, but it does imply the product parameter determines the flow. Baseline of 3 is appropriate as the schema does the heavy lifting.
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 begins a new home, auto, or bundled insurance quote and returns a quote ID. It distinguishes from sibling resume_quote by emphasizing 'new' and says 'Call this when the customer wants to get an insurance price.' The verb 'begin' is specific and the resource is clearly identified.
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 states when to use the tool ('when the customer wants to get an insurance price'). It provides extensive context on the intake order and what not to do (e.g., don't over-collect, scheduled valuables post-bind). It implies that resume_quote is for resuming, but does not explicitly exclude alternatives. Overall, clear usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
submit_leadAInspect
Capture a lead for an insurance product Libertas doesn't quote inline (renters, life, commercial, motorcycle, boat, RV, umbrella, condo, landlord, etc.) — OR any home/auto customer who asks to be contacted later instead of finishing the quote in chat. Creates a row in the CRM Leads bucket so a licensed agent can follow up.
CALL THIS WHEN:
The customer asks about an insurance type other than home/auto/bundle, AND has shared a name + email or phone. Confirm with the customer that you're going to have someone reach out, then call this tool.
The customer says "have someone call me later" or similar even on a home/auto inquiry.
The customer mentions an unusual circumstance and wants a human follow-up.
DO NOT CALL WHEN:
The customer is still actively answering questions in the home/auto intake flow — keep going through the regular intake.
You don't have any contact info yet — ask for name + email/phone first.
What it does: writes a Leads row tagged with the line of interest, contact info, preferred follow-up time, and any notes you supply. A licensed Libertas agent will reach out within one business day. Returns a confirmation message you can paraphrase to the customer ("you're on our list — someone from the team will reach out about [interest]").
| Name | Required | Description | Default |
|---|---|---|---|
| No | Customer email. | ||
| notes | No | Optional notes for the follow-up. | |
| phone | No | Customer phone number. | |
| interest | Yes | What the customer wants us to follow up about (e.g. 'renters insurance', 'life insurance', 'commercial auto') | |
| quote_id | No | Optional quote id to associate the lead with. | |
| last_name | No | Customer last name. | |
| first_name | No | Customer first name. | |
| preferred_contact_time | No | e.g. 'weekday afternoons', 'after 5pm', 'tomorrow morning' | |
| preferred_contact_method | No | How the customer prefers to be reached: 'phone', 'email', 'text', or 'any'. |
Output Schema
| Name | Required | Description |
|---|---|---|
| ok | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With annotations already providing readOnlyHint=false, destructiveHint=false, the description adds significant behavioral context: creates a CRM row, tags with interest, licensed agent follows up within one business day, returns a confirmation. 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?
Well-structured with a clear summary, separate WHEN/NOT sections, and a concise 'what it does' paragraph. Every sentence adds value; 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 high schema coverage, annotations, and the presence of an output schema (though not shown), the description is complete. It covers all necessary aspects: purpose, trigger conditions, parameter context, and expected behavior.
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 100%, so baseline is 3. The description adds context like 'writes a Leads row tagged with the line of interest' and explains the purpose of the returned confirmation message, providing meaning beyond parameter names.
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?
Clearly states the tool captures a lead for insurance products not quoted inline or for customers requesting follow-up, with specific examples (renters, life, etc.). Distinguishes from siblings by emphasizing offline CRM vs. 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?
Explicit 'CALL THIS WHEN' and 'DO NOT CALL WHEN' sections provide concrete conditions (e.g., customer asks about non-home/auto insurance, says 'have someone call me later'). Tells when not to use (e.g., during active intake, missing contact info).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
update_quoteAIdempotentInspect
Set or refine any quote parameter except regulated enrichment fields (credit score, MVR, CLUE, VIN-decoded vehicle attributes, public-record property attributes). Idempotent — call as many times as needed; the most recent value wins. Returns which fields were applied, which were rejected (with reasons), and whether the quote has enough info to run.
WHEN TO CALL:
After collecting the required-minimum from the customer in start_quote
Whenever the customer changes their mind about any coverage, deductible, discount, payment plan, or term length
When the customer shares a declarations page and you have new values to sync
CONVERSATION STYLE for coverages (per Kyle, the agency principal): After the first rates land, walk through major coverages one-or-two-at-a-time with a soft-sell framing. Example: "You have $200,000 of personal property coverage on this quote — that's the carrier's minimum and you can only go up. Does that sound like enough for your stuff?" Let the customer pick. Then call update_quote with the new value and get_quote_options again — re-quoting is free and fast (10–60 seconds).
REGULATED FIELDS (will be rejected with structured reason): drivers[].license_number, .ssn, .mvr_, .credit_score; payment fields; carrier name; vin_decoded_attributes. The system pulls these directly from the bureaus at quote time or collects them at bind on libertasinsurance.com.
| Name | Required | Description | Default |
|---|---|---|---|
| patch | Yes | Free-form patch onto the quote. Top-level branches: pni, drivers[], vehicles[], property, coverages, discounts, policy_terms, prior_insurance, has_mortgagee, mortgage_billed_by_lender, mortgagee, is_new_purchase, current_address (only when is_new_purchase=true — customer's address TODAY; property.address remains the home being insured), follow_ups[] (post-bind follow-up flags: {interest, note} — scheduled valuables like jewelry/art, umbrella interest, etc.; recorded for the licensed team, NEVER added to the in-flight quote). See the override matrix in the Libertas MCP docs for the full overridable field list. | |
| quote_id | Yes | The quote session id returned by start_quote. | |
| meta_codes | No | Optional internal meta codes; ignored unless recognized. |
Output Schema
| Name | Required | Description |
|---|---|---|
| applied | No | |
| quote_id | No | |
| rejected | No | |
| completeness | No | |
| ready_to_quote | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (idempotentHint=true), the description adds critical behavioral details: it is idempotent (most recent value wins), returns which fields were applied/rejected with reasons, and indicates whether the quote has enough info to run. It also lists regulated fields that will be rejected, 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?
The description is well-structured with sections and front-loaded with the main purpose. However, it is somewhat verbose, particularly the conversational style example which could be considered extraneous for a tool description. Still, it remains readable and the sections aid quick scanning.
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 objects, many parameters) and the presence of an output schema, the description is highly complete. It covers when to call, what fields can be set, what is rejected, idempotence, return values, and references external documentation for the full override matrix. No gaps are apparent.
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?
Although schema coverage is 100%, the description adds significant meaning: it explains the 'patch' parameter as free-form with top-level branches, describes special cases like current_address, and notes follow_ups for post-bind. It also clarifies that quote_id is from start_quote and meta_codes are ignored unless recognized, providing context not in 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 tool's purpose: 'Set or refine any quote parameter except regulated enrichment fields'. It includes idempotent behavior and return values, and distinguishes from sibling tools like start_quote and get_quote_options by specifying it is called after initial setup.
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 'WHEN TO CALL' section explicitly lists three scenarios for using the tool, including after start_quote and when customers change their minds. It also specifies what not to set (regulated fields) and provides conversational guidance. This clearly differentiates from siblings 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.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!