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.5/5 across 11 of 11 tools scored.
Each tool targets a distinct step in the quoting workflow (eligibility, start, update, status, options, details, binding, resume, lead capture). Some overlap exists between get_bind_link and request_bind_inline, but descriptions clarify usage. Overall clear.
All tools follow a consistent verb_noun pattern using snake_case (e.g., check_eligibility, get_quote_options, request_bind_inline). No mixing of conventions.
11 tools cover the insurance quoting lifecycle well. The number is appropriate for the domain without being sparse or overwhelming.
The tool set covers the major steps: eligibility, quoting, status, options, updates, binding, and lead capture. Missing a quote cancellation or decline tool, but core workflows are complete.
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 declare readOnlyHint=true, indicating a safe read operation. The description adds that it returns whether quoting and binding are available along with a plain-language explanation. This provides useful behavioral context beyond the annotations, such as the return format and its purpose.
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 the main purpose stated upfront. Every sentence adds value: the core action, when to use, automatic state handling, and return values. 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 the tool's simplicity and the presence of rich schema and annotations, the description covers all necessary context: when to call, what it does, what it returns, and how parameters relate to the process. The output schema is mentioned implicitly via the return 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 coverage is 100% with both parameters fully described via enums and descriptions. The description adds no extra semantics for the parameters themselves but clarifies that state is not a parameter (it's from context). Baseline 3 is appropriate since the schema already does a good job.
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: 'Confirm whether Libertas can quote and bind insurance for the customer in their state.' It uses specific verbs and resources, and distinguishes itself from siblings by being the initial eligibility check before collecting personal details.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly instructs to call this tool first, before collecting personal details, when the customer asks about insurance prices, switching carriers, or shopping for coverage. It also clarifies that the state is supplied automatically, so the agent does not need to ask the customer.
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.
'needs_data' — carriers can't rate until the customer supplies the fields in needs.prompts (e.g. a driver's license number, a VIN, or an additional driver's name/date of birth — each prompt says who/what it's for). Ask the customer conversationally, apply the answers with update_quote (the prompt 'field' values are the exact patch paths, e.g. drivers[1].date_of_birth), then call get_quote_options to re-run. Repeat as many times as it takes — this is an ask, NOT a failure. needs may also ride along with 'quoted' when one line rated and the other still needs info.
'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 |
|---|---|---|
| needs | No | |
| 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 far exceeds the annotations (readOnlyHint, openWorldHint) by fully explaining the polling behavior, all possible return values, their implications, and what actions to take. It also discloses constraints like not mentioning carrier counts or names, providing complete transparency.
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 longer but well-structured with bullet points for each status. It front-loads the purpose and each sentence earns its place given the complexity. Could be slightly more concise, but 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?
With an output schema present, the description still provides comprehensive return value explanations for all states, edge cases (timeout, error, needs_data), and integration with sibling tools like update_quote and get_quote_options. It is fully complete for a polling 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?
Input schema covers both parameters with descriptions. The description adds context on how quote_id is used and the default/range for max_options. It also explains how max_options affects the number of options per line, enhancing understanding beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Check rating + live-finishing progress' and specifies the context: 'Call between wait-phase questions'. It distinguishes from sibling tools by detailing the return statuses and actions, making the tool's purpose unambiguous.
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 timing guidance: 'Call between wait-phase questions (every customer turn or two after get_quote_options)'. It gives detailed instructions for each return status, including when to retry, ask for data, or proceed. However, it does not explicitly state when not to use this tool.
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 already declare readOnlyHint=true. The description adds key behavioral context: 'Carrier name remains masked.' This goes beyond annotations, though no other side effects are noted.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no wasted words. Front-loaded with the main purpose and ends with usage guidance. Perfectly sized.
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 a full schema, read-only annotation, and output schema present, the description adds just enough to understand when and what to use. 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%. The description references option_id example 'opt_home_a' and links to get_quote_options, adding practical context beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool pulls specific details (coverage breakdown, deductibles, discounts, payment plans) for a single masked option. It distinguishes itself from sibling tools like get_quote_options by specifying deeper detail.
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 mention when not to use, but the context of sibling tools and the read-only annotation implies no caveats.
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 — no payment is collected and no coverage starts from this call; a licensed agent completes underwriting verification, payment, and carrier confirmation afterward, and the customer can still change or cancel the request. Because this step is non-binding and reversible, the customer's own clear choice ("I'd like to go with Carrier A", "let's do A and A", "I'll take Carrier B") is sufficient confirmation to submit — an additional "are you sure?" prompt is not required, though you should always honor your own platform's confirmation practices. 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 it is non-binding, reversible, and triggers a follow-up by licensed agents. Adds context beyond annotations (readOnlyHint=false, etc.) and does not contradict them.
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?
First sentence states purpose, then adds necessary caveats. Every sentence provides value, though slightly long. Could be more concise but remains focused.
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 behavioral context and usage guidelines well. Output schema exists, so return values are handled. Completeness is strong for a complex tool with 8 parameters and nested objects.
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 schema already documents parameters. The description does not add additional parameter-level meaning, but baseline is 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states 'Submit the customer's bind request from the chat' and distinguishes from instant bind by explaining it triggers an internal task. Differentiates from siblings like get_bind_link 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?
Explicitly warns it is not instant bind, explains no payment, and gives guidance on customer confirmation being sufficient. Also includes a prohibition on naming real carriers, which is actionable.
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!