Quotor
Server Details
Real, bindable home & auto insurance quotes via MCP — actual carrier rates, not estimates. Texas today, expanding across the US. Agents check eligibility, run a live multi-carrier quote, compare carrier-masked options, and hand the customer a secure link for a licensed agent to finalize the bind (never an automated purchase). 11 tools; read-only tools are open, quoting/binding tools use a free self-serve API key.
- 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.4/5 across 11 of 11 tools scored.
Each tool targets a specific stage of the insurance quoting workflow (eligibility, intake, quoting, status checking, detail viewing, binding, lead capture). There is no overlap; for example, check_quote_status and get_quote_options serve distinct purposes (initiation vs. progress monitoring).
All tool names follow a consistent verb_noun pattern with underscores (e.g., check_eligibility, get_quote_options). The naming is predictable and intuitive, aiding agent selection.
With 11 tools, the set is well-scoped for an insurance quoting assistant. Each tool addresses a necessary function without redundancy or bloat, covering the core workflow from eligibility to binding.
The tools cover the essential lifecycle: eligibility, intake, quoting, status monitoring, options details, binding, late-arrival improvements, resume, and lead capture. Minor gaps exist (e.g., no cancel/modify post-bind), but these are likely out of scope for the quoting phase.
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 declare readOnlyHint and openWorldHint. Description adds concrete return details: 'whether quoting is available, whether binding is available, and 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, front-loaded with action, no filler. Each sentence adds value: purpose, usage sequence, auto-supplied state, and return summary.
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 low parameter count, clear annotations, and presence of output schema, the description fully equips the agent to use the tool correctly.
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 3. Description mentions 'product' and 'intent' implicitly and adds important context about state being from request context. Adds value but doesn't go beyond what schema already conveys clearly.
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: 'Confirm whether Libertas can quote and bind insurance for the customer in their state.' It uses specific verb ('confirm') and resource ('Libertas' ability'), distinguishing it from sibling tools like start_quote or check_quote_status.
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 guidance: 'Call this first — before collecting any personal details — when the customer asks about insurance prices...' Also clarifies that state is auto-supplied, avoiding unnecessary prompts. No explicit 'when not to use' but context is clear.
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?
Annotations provide readOnlyHint=true and openWorldHint=true. The description adds significant behavioral detail: fresh read, threshold condition (>= $100/yr or >= 5%), and auto-updating iframe. 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?
Well-structured with bullet points and clear sections. Front-loaded with purpose. Every sentence adds value, 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?
Covers trigger conditions, threshold logic, result interpretation, and integration with iframe updates. Given output schema exists, description is sufficiently 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?
Only one parameter (quote_id) with 100% schema coverage. The description does not add extra semantics beyond the schema, which is adequate for a single string parameter.
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: to check for late-arriving carrier rates when a customer shows price resistance. It distinguishes itself from siblings like check_quote_status and get_quote_options by specifying its unique trigger and outcome.
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 provides 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 committing, hasn't seen options). Also gives result handling guidance.
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 goes far beyond the annotations (readOnlyHint=true, openWorldHint=true) by detailing the exact behavior for each return status: 'running' means keep polling, 'quoted' involves checking finishing.active which affects how prices are presented, and includes warnings about not mentioning carrier counts or names. It also describes how cards harden to 'verified' automatically, providing rich behavioral context that is critical for correct agent 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 well-structured with a clear opening sentence, bullet points for each return status, and explicit don'ts. It is somewhat lengthy but every sentence adds value given the complexity of the tool's behavior. It could be slightly more concise (e.g., merging some points), but overall 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 states, dynamic finishing process, nested fields like options[], finishing), the description thoroughly explains all aspects: what each status means, how to handle quoted state with finishing.active true/false, and what to do on errors. The presence of an output schema is noted, but the description already covers the return values comprehensively. No gaps remain.
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 provides full coverage (100%) for both parameters (quote_id and max_options) with clear descriptions. The tool description does not add any additional meaning beyond what the schema already conveys; it focuses on the return behavior instead. Baseline 3 is appropriate since the schema does the heavy lifting, and the description adds no extra parameter 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 the tool's purpose: 'Check rating + live-finishing progress.' It specifies the context for use ('Call between wait-phase questions, every customer turn or two after get_quote_options'), which distinguishes it from sibling tools like get_quote_options or get_option_details. The verb 'check' and resource 'quote status' plus the detailed explanation of return states make the purpose explicit and unique.
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 usage guidance: 'Call between wait-phase questions' and explains what to do for each return status (e.g., for 'running' continue polling, for 'quoted' check finishing block, for 'timeout' offer to retry). It gives clear context but does not explicitly list when NOT to use the tool, though the specificity of the polling scenario implies appropriate use. Sibling tools are not directly compared, but the description's context is strong enough to guide an agent.
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?
Annotations are minimal (only readOnlyHint=false). The description adds valuable behavioral context: the link is single-use, secure, valid 7 days, and reveals the real carrier name. It does not contradict 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 concise and well-structured, with front-loaded main action and every sentence providing necessary information: action, alternative, use cases, and a special detail about carrier name reveal.
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 complete schema coverage, presence of output schema, and descriptive annotations, the description fully covers the tool's purpose, usage contexts, and behavioral nuances without 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 coverage is 100% with simple parameter descriptions. The tool description does not elaborate on parameter semantics beyond what the schema provides, 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 generates a single-use secure link valid for 7 days, with a specific resource (Libertas bind-request page). It distinguishes itself from the sibling tool request_bind_inline by specifying when each should be used.
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: prefer request_bind_inline for in-chat flow, and use get_bind_link when the customer wants to leave chat, use a different device, or have numbers emailed. It also mentions pairing with an email offer during long waits.
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 include readOnlyHint=true, so the description does not need to restate that. The description adds behavioral context by noting that the carrier name remains masked, which is valuable for understanding output limitations.
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, each providing essential information: what it does, when to use it, and a notable behavioral detail. No extraneous content.
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 does not need to detail return values. It covers the tool's purpose, usage context, and a key constraint, fitting well with the sibling set of quote-related tools.
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 already documented. The description adds meaning by hinting that option_id comes from get_quote_options, connecting the tool to its sibling.
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 'Pull' and specifies the resource: full coverage breakdown, deductibles, discounts, and payment plans for a single masked option. It distinguishes from siblings like get_quote_options by focusing on detailed breakdown rather than listing 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 states when to use: 'when the customer wants to dig into a specific quote before deciding.' Does not explicitly mention when not to use, but the context is sufficiently clear given the sibling tools.
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?
Describes the two-stage process, timing (30-90 seconds for first numbers, 2-10 minutes for hardening), and how options surface as ranges then become verified. This goes beyond annotations (openWorldHint, idempotentHint) to explain exact 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?
Well-structured with clear sections, but a bit lengthy. Front-loaded with the core action. Every sentence adds value, but could be slightly more concise without losing important guidance.
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 (async behavior, multiple stages), the description covers key aspects: timing, state transitions, agent actions during wait, and when to re-call. However, it omits error handling and edge cases.
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 significant new semantics beyond the schema for the two parameters; 'waters toggle locally' is mentioned but not directly tied to parameters.
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' and emphasizes it returns immediately. It distinguishes from sibling tools like check_quote_status which reports the finishing 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?
Provides explicit guidance: when to call again ('only if a rating-changing input changes'), what to do during the wait ('keep the conversation going...'), and what not to do ('never quantify carriers or name them'). Also differentiates from check_quote_status for status updates.
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 bind is not instant, requires subsequent steps. Provides important constraint about not naming real carriers in output. Annotations already indicate mutability and non-idempotency; description adds context on task creation and agent follow-up.
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 somewhat verbose with imperative instructions and repeated clarifications. Could be streamlined while retaining key points.
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 trigger conditions and usage rules well. With output schema present, it appropriately omits return value details. Could briefly mention expected output or confirmation of task creation.
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 schema already documents all parameters. Description adds minor context (e.g., water_selections are for home options) but does not significantly enhance beyond 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?
Description clearly states the tool submits a bind request from chat and triggers an internal task. It distinguishes itself from 'instant bind' and sibling tools like 'get_bind_link'.
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 specifies when to call: the moment the customer expresses intent to go with a carrier. Includes instruction to not ask redundant confirmation. Lacks mention of when not to use or alternatives to other tools.
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 indicate readOnlyHint and openWorldHint. The description adds behavioral details beyond annotations, such as return values (status, summary, rate options availability) and verification conditions (email code if different user). 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 two sentences, efficient, and front-loaded with the main purpose. The second sentence is longer but packs necessary context. Could be slightly more structured but overall concise 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 the tool's complexity (2 parameters, nested verification object, output schema exists), the description explains the return value sufficiently (status, summary, rate options). It covers the verification flow and session continuity, making it complete for an AI agent to use.
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 both parameters. The description adds meaning by explaining that quote_id is supplied by the customer and that verification is conditional on user identity, which is not in the schema. This helps the agent understand parameter usage.
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 the tool's purpose: 'Pick up an existing quote that was started in a previous session or on a different platform.' It uses a specific verb ('resume') and resource ('existing quote'), distinguishing it from siblings like start_quote.
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?
Description provides clear context on when to use (resuming a quote from a previous session/platform) and explains verification requirements based on user identity. It does not explicitly name alternatives but the sibling list suggests start_quote as the primary alternative.
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 basic flags, but the description adds extensive behavioral details: return value (quote ID), intake order, instruction to call get_quote_options immediately, and what to avoid (over-collect, probing roof, mid-quote additions). 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 long but well-structured with clear sections. The first sentence is concise. The intake order is necessary for correct usage. Minor redundancy could be trimmed, but overall structure is effective.
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 complex tool, the description is remarkably complete: covers return value, step-by-step intake order, when to call next tool, and edge cases (roof unknown, post-bind follow-ups). Output schema exists but description covers key 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 coverage is 100%, so the description adds minimal value beyond the schema. The product parameter's enum is restated. Optional params are briefly mentioned. 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's purpose: 'Begin a new home, auto, or bundled insurance quote. Returns a quote ID to use on every following call.' It specifies the verb (begin), resource (insurance quote), and product types, distinguishing it from siblings like resume_quote.
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 usage context: 'Call this when the customer wants to get an insurance price.' It does not explicitly contrast with alternatives, but the detailed intake order implies proper usage. Missing explicit when-not-to-use guidance prevents a higher score.
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?
Description discloses it creates a Leads row in CRM and returns a confirmation message. Annotations indicate mutation (readOnlyHint=false). No contradictions. Adds detail about agent follow-up within one business day.
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 clear sections (CAPTURE, CALL THIS WHEN, DO NOT CALL WHEN, What it does). Slightly long but efficient and front-loaded with main purpose.
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 9 parameters, required interest, high schema coverage, and presence of output schema, the description fully covers usage, exclusions, and expected output. 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 coverage is 100% with descriptions for all 9 parameters. Description reinforces the purpose of parameters like interest, contact info, preferred time/method but doesn't add significant new meaning beyond 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?
Description clearly states the tool captures leads for insurance products not quoted inline or when customers want follow-up. It distinguishes from sibling tools like check_eligibility, start_quote, etc. which handle different functions.
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 when-to-call scenarios (customer asks about non-inline product, requests later contact, unusual circumstance) and when-not-to-call (active intake, no contact info). Names alternative (continue intake).
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?
The description explicitly states the tool is idempotent ('call as many times as needed; the most recent value wins'), which aligns with the annotation idempotentHint=true. It also discloses that regulated fields are rejected with structured reasons, and describes the return value composition (applied fields, rejected fields, enough info check). 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?
The description is well-organized with sections, bold headings, and examples. The main purpose and idempotency are front-loaded. However, the conversation style example, while helpful, adds verbosity. Minor redundancy could be trimmed without losing clarity, but overall structure earns a high score.
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 three parameters (one nested object), the presence of an output schema, and the need to guide tool invocation in a conversational context, the description is comprehensive. It covers call frequency, regulated fields, return information, and even provides a soft-sell framing example. The reference to an external matrix for advanced usage is acceptable.
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%, yet the description adds significant meaning beyond the schema. It explains the patch parameter as a free-form object with top-level branches, clarifies special cases (current_address vs property.address), and references an external matrix for the full overridable field list. This helps the agent understand how to construct valid patches.
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 action ('Set or refine any quote parameter') and identifies the resource ('quote'), with specificity about what is excluded ('except regulated enrichment fields'). It distinguishes itself from sibling tools like start_quote and get_quote_options by focusing on updating existing quotes.
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 a dedicated 'WHEN TO CALL' section listing three clear scenarios (after start_quote, customer changes mind, new values to sync). It also explains what NOT to do by listing regulated fields that will be rejected, giving explicit guidance on when this tool should not be used for those fields.
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!