Sigo Seguros car insurance quotes
Server Details
Non-binding car insurance estimates from Sigo Seguros, a licensed agency, not a carrier.
- Status
- Healthy
- Uptime
- 100.0% over 38 days
- Last Tested
- Transport
- Streamable HTTP · MCP 2025-11-25
- URL
- ChatGPT
- –
- Claude
- –
TDQS
Scored across 12 tools
The live flow tools (next_question, start_quote, get_quote, carrier_questions, answer_carrier_questions) are clearly distinct steps. However, the surface carries two retired stubs (other_carrier_questions, answer_other_carrier_questions) that shadow the live carrier_questions/answer_carrier_questions names and exist only to redirect, which is a real misselection hazard. next_question vs commercial_next_question and find_occupation as an out-of-band helper add minor boundary blur.
Most names are snake_case verb_noun (start_quote, get_quote, list_available_states, find_occupation, submit_commercial_application). But several are noun-first question-returning tools (next_question, commercial_next_question, carrier_questions) that don't parallel the verb-led set, and the commercial path uses a different prefix pattern than the personal path. Readable, but conventions are mixed.
12 tools map well onto a multi-stage quote funnel plus a commercial branch and link-resolution helper. Two of the twelve are retired no-op stubs, so the effective surface is 10, which is well within scope.
The lifecycle is covered end to end: state eligibility, staged intake, quote start, polling, carrier question pass, revision via revise_of, commercial intake and submission, plus link resolution for returning customers. Binding/payment is deliberately excluded (handled in Sigo's link), so leaving it out is correct rather than a gap. Only real weakness is the stubs retained instead of removed.
Available Tools
12 toolsanswer_carrier_questionsFile the customer's answers to the carrier's questionsAIdempotentInspect
After carrier_questions: file the answers, passing answers_so_far back each time, until the set is complete.
Saves what the customer answered against their application, which is what moves it towards a final quote. Send every answer under the code it came back with, and only what the customer actually said.
This does not take payment, sign anything or bind coverage. Those happen in Sigo's own flow, through the link that comes back here.
The carrier takes its questions as a set, so answers are held until every one has been given. Pass the answers_so_far from the previous call back in, and only the new answer needs to go in answers. On the four-carrier path the whole pass is filed at once and next_call sends you to get_quote, where the firm prices land.
| Name | Required | Description | Default |
|---|---|---|---|
| locale | Yes | The language the customer is writing in. Set it from their own messages rather than leaving the default: the estimate's notice comes back in this language, and a notice the customer cannot read discloses nothing. Sigo serves these two languages only. | |
| answers | Yes | What the customer said, in their own answers. Never filled in on their behalf. | |
| quote_id | Yes | The handle start_quote returned. | |
| answers_so_far | No | The `answers_so_far` from the previous call, when there was one. It carries what the customer already answered, so only the new answer needs to go in `answers`. It survives a re-quote: after start_quote with revise_of, send the same token with the new quote_id and the answers still stand, as long as the carrier is the same one. Nobody has to be asked twice. | |
| chosen_quote_id | No | The estimate the customer picked. Left out on the four-carrier path, as at carrier_questions. |
Output Schema
| Name | Required | Description |
|---|---|---|
| note | Yes | What is done and what is still ahead, in the customer's language. |
| filed | Yes | True once the carrier has the whole set. The carrier takes it whole or not at all, so answers are held until every required question has one. |
| answered | Yes | How many of the carrier's questions have an answer so far, counting the earlier turns. |
| next_call | Yes | Exactly what to call next, with its arguments, when something follows here; null otherwise. |
| next_step | Yes | Paying and signing happen here, not in this conversation. |
| still_needed | Yes | The codes of the required questions with no answer yet. Empty when the set is complete. |
| answers_so_far | Yes | Everything answered up to now, to pass back on the next call so nothing is lost. Null once the carrier has the set and there is nothing left to carry. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well beyond the annotations: it discloses that answers are held until the full set is given, that answers_so_far survives a re-quote when the carrier is unchanged, and that no payment, signature, or binding happens here. The annotations already assert idempotentHint and destructiveHint=false, but the description explains the mechanism behind those hints rather than restating 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?
Front-loads the trigger ('After carrier_questions') and keeps every sentence load-bearing, covering the loop, the exclusions, and the four-carrier variant. Some phrasing is circuitous ('Those happen in Sigo's own flow, through the link that comes back here') but nothing is truly wasted.
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?
An output schema exists, so return values need no explanation, and the description covers the accumulation token, the non-binding scope, and the alternate four-carrier path. The one real omission is sibling differentiation against answer_other_carrier_questions, which is the most likely selection error for this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and the parameter docs are already detailed (locale, answers_so_far persistence, code fidelity), so the baseline is 3. The description reinforces the code/value discipline but adds no format or syntax detail beyond what the schema already provides.
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?
States a specific verb and resource ('file the answers' against the application) and anchors the tool to its predecessor, carrier_questions. However, it never distinguishes itself from the near-identically named sibling answer_other_carrier_questions, leaving the agent to infer which of the two applies.
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?
Gives clear sequencing ('After carrier_questions... until the set is complete') and describes the loop mechanic of passing answers_so_far back each time, plus the four-carrier batch path that routes to get_quote. The missing piece is explicit routing versus answer_other_carrier_questions, which an agent must resolve on its own.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
answer_other_carrier_questionsRetired: file the other carriers' answersAIdempotentInspect
Retired. Do not call it: answer_carrier_questions files the one pass for every carrier, and get_quote carries the firm prices in firm_prices.
Kept so an older conversation that reaches it is told where to go, with the link. It files nothing.
| Name | Required | Description | Default |
|---|---|---|---|
| locale | Yes | The language the customer is writing in. Set it from their own messages rather than leaving the default: the estimate's notice comes back in this language, and a notice the customer cannot read discloses nothing. Sigo serves these two languages only. | |
| answers | Yes | What the customer said, in their own answers. Never filled in on their behalf. | |
| quote_id | Yes | The handle start_quote returned. | |
| answers_so_far | No | Ignored: nothing is carried here any more. |
Output Schema
| Name | Required | Description |
|---|---|---|
| note | Yes | What is done and what is still ahead, in the customer's language. |
| filed | Yes | Always false: nothing is filed here any more. answer_carrier_questions files the one pass. |
| answered | Yes | How many of the carrier's questions have an answer so far, counting the earlier turns. |
| next_step | Yes | Paying and signing happen through the link, after an agent confirms. |
| still_needed | Yes | The codes of the required questions with no answer yet. Empty when the set is complete. |
| answers_so_far | Yes | Everything answered up to now, to pass back on the next call so nothing is lost. Null once the carrier has the set and there is nothing left to carry. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations declare readOnlyHint=false, i.e. a potentially mutating operation, while the description flatly states 'It files nothing' and 'Kept so an older conversation that reaches it is told where to go'. Those two signals conflict about whether invoking this tool has side effects, which is the annotation-contradiction case. Although the description's advice is the correct/helpful one, the structured and unstructured data disagree about the write 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?
Three short sentences, front-loaded with the retirement and prohibition, then the routing targets, then the reassurance that it files nothing. No filler, nothing repeated from the schema.
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 retired tombstone tool with an output schema present, the description covers everything an agent needs: status, prohibition, successor tools, and the fact that invoking it accomplishes nothing. No return-value explanation is required.
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%, and each parameter (locale, answers, quote_id, answers_so_far) is documented in the schema itself — including that answers_so_far is ignored. The description adds no parameter-level meaning beyond that, so the baseline of 3 applies for a schema that does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The very first word, 'Retired. Do not call it:', states the tool's status and its effective behavior ('It files nothing'), and the description names the replacements (answer_carrier_questions, get_quote) so an agent can route without opening any sibling schema. There is no ambiguity about what this tool does or does not do.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives an explicit prohibition ('Do not call it') plus the exact alternatives to use instead and what each carries ('answer_carrier_questions files the one pass for every carrier', 'get_quote carries the firm prices'). It also explains why it still exists — to redirect older conversations that reach it — which is precisely the when/when-not guidance the rubric asks for.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
carrier_questionsThe carriers' own questions before a firm priceARead-onlyInspect
After the three steps, when to_final_quote.next_call names it: the questions of the estimate the customer picked, or of every carrier at once when get_quote carries firm_prices (then no chosen_quote_id). Then answer_carrier_questions.
Returns the questions the carrier asks in the customer's state — attestations and disclosures the carrier words itself; on the four-carrier path, every carrier's, once. Say preamble first, then ask one ask_together block per turn, each question exactly as it is worded; they are not Sigo's questions to reword. Send the answers with answer_carrier_questions.
can_answer_here is false where that carrier does not finish online, or the answers were already filed; a Sigo agent takes it, or get_quote has the prices. Either way the customer keeps the link: they can finish on the web at any point without losing what they have answered.
| Name | Required | Description | Default |
|---|---|---|---|
| locale | Yes | The language the customer is writing in. Set it from their own messages rather than leaving the default: the estimate's notice comes back in this language, and a notice the customer cannot read discloses nothing. Sigo serves these two languages only. | |
| quote_id | Yes | The handle start_quote returned. | |
| chosen_quote_id | No | The `quote_id` of the estimate the customer picked, from the list they were shown. Leave it out when get_quote answered with a `firm_prices` block: there the questions are the same for every carrier. |
Output Schema
| Name | Required | Description |
|---|---|---|
| note | Yes | How to put these, in the customer's language. |
| preamble | Yes | Sigo's own words for the customer, to say as they are before the first question. Not one of the carrier's questions and not answered. Null when there is nothing to ask here. |
| next_step | Yes | Where the customer finishes. Theirs at any point, not only at the end. |
| questions | Yes | In the order the platform ranked them. |
| ask_together | Yes | Codes that can be put to the customer in one turn, grouped the way the carrier groups them. Ask each block as one message and send its answers together. A question with `depends_on` is in no block: it gets its own turn, after the one it hangs off. Empty when there is nothing to ask here. |
| still_needed | Yes | What the application still lacks, when that is why the questions are not here. An empty array means nothing is missing. Null means this is not about the application at all — either the questions came back, or the carrier does not finish online here. |
| can_answer_here | Yes | False when there is nothing to ask here: the application is still missing details, the carrier does not finish online in this state, or the answers were already filed. Check `still_needed` and `note` to tell them apart. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered; the description adds real behavioral context: emit `preamble` first, one `ask_together` block per turn, questions verbatim (not rewordable), the can_answer_here=false branches, and that the customer retains the web link without losing answers. That is meaningful disclosure beyond the annotation set, though the 'no chosen_quote_id' rule is left mostly to the schema.
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 content is dense and multi-clause, with backticked identifiers woven into prose sentences. It is front-loaded with the workflow precondition rather than the purpose, and the instructions mix conditioning, emission rules and edge cases into two long paragraphs. Nothing is pure filler, but readability suffers.
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?
An output schema exists, so return-value explanation is unnecessary, and the description covers the branching logic (chosen vs. all-carrier, can_answer_here false, downstream round-trip to answer_carrier_questions) plus the locale consequence. For a read-only retrieval tool in a multi-step flow, an agent has everything needed to call it 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 description coverage is 100%, so all three parameters (including the locale rationale and the firm_prices omission rule) are already documented in the schema. The description restates the chosen_quote_id omission condition but adds no syntax or format detail the schema lacks. Baseline 3 when the schema carries the load.
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?
It states a concrete resource — the carrier's own attestation/disclosure questions for the customer's state — and distinguishes the two paths (chosen estimate vs. all carriers under firm_prices). It also implies the sibling boundary with answer_carrier_questions. However, the opening clause ('After the three steps, when to_final_quote.next_call names it') buries the purpose behind sequencing, so the agent reads workflow before it reads what the tool is.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives explicit activation conditions: after the three steps when to_final_quote.next_call names it, or when get_quote returns firm_prices. It names the follow-up tool (answer_carrier_questions) and the handoff condition (can_answer_here false). It stops short of naming the near-siblings other_carrier_questions / answer_other_carrier_questions, so the agent must infer why those exist.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
commercial_next_questionThe next commercial auto question to ask a businessARead-onlyInspect
Commercial auto, step 1 of 2: call it until ready_to_submit is true, sending back the collected it returns each time and each answer under answer_as.key. Then submit_commercial_application.
For a vehicle a business owns or uses for its work: a contractor's pickup, a delivery van, a box truck, a tow truck, a fleet. It takes the short intake Sigo's commercial form opens with, one question at a time in the customer's language, and a Sigo agent quotes it with the carriers afterwards. There is no estimate and no price here, and none to give: say any quote is subject to underwriting, eligibility and state filing.
Its first question tells a business apart from someone who drives only for Uber, Lyft, DoorDash or Uber Eats. That is personal auto: route_to_personal turns true, nothing commercial is sent, and next_question takes it from there. When it is not clear which kind of customer this is, start here.
Ask ask as the website words it, with its options, and wait for the answer. It never asks for a social security number, a FEIN or EIN, a date of birth or a licence number; do not collect them.
| Name | Required | Description | Default |
|---|---|---|---|
| locale | Yes | The language the customer is writing in. Set it from their own messages: the questions come back in it, and the request is filed in it so the Sigo agent follows up in it. | |
| answered | No | Only what the customer said this turn, under answer_as.key. Everything earlier is in `collected`. | |
| collected | No | The `collected` from the previous call. Leave it out on the first question and send it on every call after that. It is not the quote flow's collected: the two do not mix. |
Output Schema
| Name | Required | Description |
|---|---|---|
| ask | Yes | The website's own wording of the question, in the customer's language. Put it to them as it is; do not reword the options. |
| field | Yes | The question being asked, by name; `none` when there is nothing left to ask. |
| options | Yes | Every choice the customer may pick, when the question has a fixed set, in answer_as.values order. |
| summary | Yes | What the customer answered, to read back before submitting. Only when ready_to_submit is true. |
| answer_as | Yes | How to send the answer back. Null once nothing is left to ask. |
| collected | Yes | Everything answered so far, this turn included. Send it back on the next call. |
| next_step | Yes | Present when the intake ends: what to call next. |
| ready_to_submit | Yes | True when every question is answered: read the summary back, then submit_commercial_application. |
| route_to_personal | Yes | True when the customer drives only for apps: that is personal auto, nothing commercial is sent, and next_question takes it from here. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare a safe read-only, non-destructive operation, but the description adds substantial context: the loop terminates on ready_to_submit, no estimate or price is produced (with the compliance phrasing to use), and there is an explicit do-not-collect list (SSN, FEIN/EIN, DOB, licence number). It also instructs to ask `ask` verbatim with its options and wait — real behavioral guidance beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The scope/loop and the submit hand-off are front-loaded, and every paragraph carries distinct information (flow, customer-type routing, no-pricing stance, prohibited fields). However, some sentences are grammatically tangled and dense ('sending back the collected it returns each time'), which slightly hurts scannability.
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?
Output schema exists so return values need not be explained, and the description still covers the loop termination condition, the personal-vs-commercial routing decision, the hand-off tool, and the compliance/data-collection boundaries. For a stateful, multi-step intake tool this is complete enough to call 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 description coverage is 100%, so the baseline is 3, but the description adds the round-trip protocol — send back the returned `collected` on every call after the first and pass each turn's answer under answer_as.key — plus the warning that this `collected` is not the quote flow's. That meaningfully clarifies how the 3 parameters are threaded across calls.
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 opening line states exactly what the tool returns — the next commercial auto intake question — and frames it as 'step 1 of 2' of a named flow. It explicitly contrasts the resource with personal auto (route_to_personal / next_question) and with submit_commercial_application, so an agent can place it among siblings without opening a schema.
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?
Gives concrete when-to-use rules: call repeatedly until ready_to_submit is true, echoing `collected` and each answer under answer_as.key, then hand off to submit_commercial_application. It also names the alternative path explicitly (personal-auto drivers route to next_question) and says 'When it is not clear which kind of customer this is, start here.'
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
find_occupationFind the rater's code for a customer's jobARead-onlyInspect
Second-round helper, outside the three steps: turns the customer's words into the occupation code start_quote takes.
Turns what the customer said they do into the carrier's own occupation codes. Call it before sending occupation on a driver: the catalogue is written in trade names and customers answer in their own, so the code is never something to guess at. Pick the entry that matches what they described and send its code.
An empty list means ask them another way rather than settle for the nearest thing.
| Name | Required | Description | Default |
|---|---|---|---|
| said | Yes | What the customer said they do, in their own words — 'chofer', 'trabajo en construcción'. | |
| locale | Yes | The language the customer is writing in. Set it from their own messages rather than leaving the default: the estimate's notice comes back in this language, and a notice the customer cannot read discloses nothing. Sigo serves these two languages only. |
Output Schema
| Name | Required | Description |
|---|---|---|
| note | Yes | What to do with this list, in the customer's language — including when it comes back empty. |
| matches | Yes | The rater's entries that fit, best first. Pick the one that matches what the customer described and send its `code` as the driver's `occupation`. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/openWorld/non-destructive, so safety is covered. The description adds genuinely useful behavior beyond that: an empty list is a legitimate outcome and should prompt re-asking rather than a nearest-match guess, which shapes agent policy on error handling. It does not discuss latency, rate limits, or how many candidate entries typically come back.
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?
Front-loaded with the tool's role, then when to call it, then the failure case — good ordering with no filler. Slight redundancy between the opening sentence and 'Turns what the customer said they do into the carrier's own occupation codes', which restates the same mapping twice.
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, return structure need not be described, and the description covers the one output condition that matters behaviorally (empty list). Combined with a fully documented two-parameter schema and safety annotations, an agent has what it needs; only edge behavior like multiple equally-plausible matches goes unaddressed.
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%, including enum values and a detailed rationale for `locale`, so the schema already carries parameter meaning. The description adds no syntax or format detail for `said` or `locale` beyond the schema. Baseline 3 is appropriate when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Names a precise verb+resource relationship: converts the customer's description of their job into the carrier's occupation code that start_quote consumes. It explicitly distinguishes itself from the main flow ('Second-round helper, outside the three steps') and from the sibling start_quote, so an agent can place it without opening any schema.
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?
States the trigger ('Call it before sending `occupation` on a driver'), the reason guessing fails (catalogue is in trade names, customers answer in their own), and the fallback when the result is empty ('ask them another way rather than settle for the nearest thing'). When-to-use, why, and failure handling are all explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_quoteRead car insurance estimatesARead-onlyInspect
Step 3 of 3: read the quote_id start_quote returned, after poll_after_seconds, until more_carriers_pending is false. Never start_quote again to refresh a result.
Reads the estimates for a quote_id returned by start_quote. Carriers answer at different speeds: when more_carriers_pending is true the list is not final and poll_after_seconds says how long to wait before asking again. The list closes within a minute either way, with whatever arrived — a carrier that did not answer is not a price, and there is none to go looking for. Once it is closed, to_final_quote.next_call is what to do next. No price here is final, in any round: the final quote is calculated by Sigo in the link, after the carrier's questions.
| Name | Required | Description | Default |
|---|---|---|---|
| locale | No | The language the customer is writing in. Set it from their own messages rather than leaving the default: the estimate's notice comes back in this language, and a notice the customer cannot read discloses nothing. Sigo serves these two languages only. | es |
| quote_id | Yes | The handle start_quote returned. |
Output Schema
| Name | Required | Description |
|---|---|---|
| state | Yes | |
| covers | Yes | |
| quotes | Yes | |
| status | Yes | |
| contact | Yes | |
| carriers | Yes | |
| problems | Yes | |
| quote_id | Yes | Pass this back to get_quote to read the result again. |
| asked_for | Yes | Label each answer with this when comparing two quotes for the same customer, so "con deducible de 1000" is matched to the quote that asked for it. |
| issued_by | Yes | |
| quoted_at | Yes | |
| expires_at | Yes | |
| application | Yes | |
| firm_prices | Yes | |
| pending_note | Yes | What to do while carriers are still answering, in the customer's language. Null once the list is final. |
| price_levers | Yes | |
| to_final_quote | Yes | |
| personal_use_note | Yes | Present when the customer said the vehicle is used for work. Say it with the prices: this quote is personal auto. Null when they said nothing about it, and then the subject is not raised. |
| poll_after_seconds | Yes | How long to wait before calling get_quote again. |
| revised_from_quote | Yes | True when this quote re-quoted the same customer: started with revise_of, or for a customer who already quoted today and was still at their first round. One person, one application, priced again. |
| more_carriers_pending | Yes | True when more carriers may still return a price; the list is not final. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the read-only, open-world, non-destructive profile, but the description adds genuinely non-obvious behavior: carriers respond at different speeds, the list closes within a minute regardless, missing carriers are not a price to chase, and no returned price is final until Sigo computes it. These are operational facts an agent cannot infer from the structured fields.
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?
Front-loads the step/sequencing constraint, then the resource, then the polling mechanics. It is longer than strictly necessary and repeats the 'not final / not a price' point in two different places, but nearly every sentence carries operational information.
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?
Output schema exists, so return values need not be restated, and the description still supplies the missing flow context: what more_carriers_pending and poll_after_seconds mean, when the list closes, and that to_final_quote.next_call is the next action. Nothing an agent needs to call and correctly loop this tool is absent.
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 quote_id ('the handle start_quote returned') and locale are already fully documented in the schema. The description reinforces the quote_id provenance and the polling cycle but adds no parameter-level detail (e.g. locale, enum values) beyond what the schema provides, so the baseline 3 applies.
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?
States a specific verb (read) and resource (car insurance estimates for a quote_id), and positions itself explicitly as 'Step 3 of 3' in a flow anchored to start_quote. An agent can tell it apart from start_quote and the carrier-question siblings without opening any schema.
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?
Gives explicit sequencing ('Step 3 of 3', read the quote_id start_quote returned), a negative instruction ('Never start_quote again to refresh a result'), and the polling condition (repeat after poll_after_seconds until more_carriers_pending is false). This is about as prescriptive as usage guidance gets.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_available_statesStates where Sigo can quoteARead-onlyInspect
Before the flow, optional: where Sigo quotes. The flow itself is next_question, then start_quote once, then get_quote.
The US states Sigo Seguros is licensed to sell car insurance in, and what Sigo is. Ask this before collecting details, so a customer elsewhere is not taken through a full quote.
The state a policy is rated in comes from where the car is kept overnight, not from where the customer lives or works. Read state_is_decided_by before asking for a ZIP: a car kept outside these states is not quoted on a ZIP inside them, however close the customer commutes.
Sigo is an agency: it sells policies that carriers issue. The carrier pays it a commission, and in almost every state where it sells, the customer pays a one-time broker fee for the agency's service — in Florida there is none. Where there is one it is real and is itemised before anyone pays, in Sigo's own flow. Asked what Sigo charges — which customers ask before there is any quote — that is the answer, with no amount: saying Sigo charges nothing is false wherever it does charge, and the checkout will contradict it.
| Name | Required | Description | Default |
|---|---|---|---|
| locale | Yes | The language the customer is writing in. Set it from their own messages rather than leaving the default: the estimate's notice comes back in this language, and a notice the customer cannot read discloses nothing. Sigo serves these two languages only. |
Output Schema
| Name | Required | Description |
|---|---|---|
| states | Yes | |
| carriers | Yes | |
| how_sigo_is_paid | Yes | What to say when the customer asks what Sigo charges, in their language. No amount is in it. |
| state_is_decided_by | Yes | Read this before asking for a ZIP. It says what decides the state a policy is rated in, in the customer's language, and it is the one thing this list does not say on its own. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, non-destructive, closed-world), and the description adds substantial context beyond them: the overnight-keeping rule for determining state, the agency/carrier commission model, the one-time broker fee that is absent in Florida, and the instruction never to claim Sigo charges nothing. That is real operational guidance an agent could not derive from structured fields.
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 and meandering, opening with flow ordering rather than the tool's purpose, and spends several sentences on the agency/commission/broker-fee business model that is tangential to listing states. Some content earns its place, but the structure buries the lead and the length is not proportionate to a one-parameter list tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return values need no explanation, and the description covers the when/why and the key state-determination caveat thoroughly. It is complete for calling the tool correctly, though the core purpose statement is under-emphasized and some included material belongs to a customer-question-answering concern rather than this lookup.
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% and the sole parameter (locale) has a full enum and a detailed schema description covering language selection and consequences. The tool description adds nothing about locale, so per the baseline for full coverage this sits at 3 — the schema does all the work.
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 does state the resource clearly — 'The US states Sigo Seguros is licensed to sell car insurance in' — and distinguishes itself from the flow siblings (next_question, start_quote, get_quote). However, the actual purpose is buried after an opening sentence about flow ordering, and it conflates two jobs: listing states and explaining 'what Sigo is'. An agent can identify it, but not from a clean leading statement.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly says 'Before the flow, optional' and 'Ask this before collecting details, so a customer elsewhere is not taken through a full quote', which gives placement and rationale against alternatives. It also warns that state is decided by where the car is kept overnight, not residence — a concrete usage condition. No explicit 'when not to use', but the context and ordering are clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
next_questionThe next thing to ask the customerARead-onlyInspect
Step 1 of 3: call it until ready_to_quote is true, sending back the collected it returns each time and each answer under answer_as.key. Then start_quote.
Returns the one question to put to the customer now, in their language, with the options to offer when the field has a fixed set. Call it before each question and again after every answer, until ready_to_quote is true, then call start_quote.
Send only what the customer said this turn, in answered, together with the collected from the last call. The connector keeps the record of the conversation, so nothing is repeated and an answer given before its turn is not lost. When ready_to_quote turns true, summary is what the customer has said: read it back and let them correct it before quoting.
It exists so the order and the pace are the connector's rather than a matter of judgement: Sigo's customers are working people, often quoting on a phone, and a turn that asks for four things at once is where they give up.
Once a ZIP is given it is checked here, so a customer outside the states Sigo is licensed in is told before being walked through the rest.
There are two stretches. stage: "first_quote" is the one that ends in estimates. stage: "second_round" is for a customer who saw those estimates and wants to finish the application so the carrier can quote it for real: it asks where the car is kept, the VIN, who owns it, the licence, and a few more. The prices it leads to are still estimates; the final quote comes after the carrier's own questions, in Sigo's link. get_quote says when that is worth offering.
A vehicle a business uses for its work is commercial auto and is not quoted here: use commercial_next_question. Someone who drives only for apps like Uber or DoorDash stays here.
| Name | Required | Description | Default |
|---|---|---|---|
| stage | No | Which stretch the conversation is in. `second_round` is for a customer who saw prices and wants to finish the application; it asks a different set, and the prices it leads to are still estimates. | first_quote |
| locale | Yes | The language the customer is writing in. Set it from their own messages rather than leaving the default: the estimate's notice comes back in this language, and a notice the customer cannot read discloses nothing. Sigo serves these two languages only. | |
| answered | No | Only what the customer said this turn. Everything from earlier turns is already in `collected` and must not be repeated here. | |
| collected | No | The `collected` from the previous call. Leave it out on the first question of a conversation and send it on every call after that: it carries everything answered so far, so nothing has to be repeated and nothing is lost. |
Output Schema
| Name | Required | Description |
|---|---|---|
| ask | Yes | The question, ready to put to the customer, in their language. |
| field | Yes | The question being asked, by name. Not the key to answer under: that is `answer_as.key`. |
| options | Yes | Every choice the customer may pick, when the field has a fixed set. |
| summary | Yes | What the customer has answered, to read back to them for confirmation. Present only once `ready_to_quote` is true; null while there are still questions to ask. |
| answer_as | Yes | How to send the answer back. Null on the closing step, when there is nothing left to answer. |
| collected | Yes | Everything answered so far, this turn included. Send it back on the next call. It is the connector's record of the conversation, so nothing has to be asked twice. |
| ready_to_quote | Yes | True when nothing is missing and start_quote can be called. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnlyHint=true, destructiveHint=false, openWorldHint=false), so the bar is lower. The description does add real behavior beyond that: the connector owns conversation state, `collected` must be round-tripped, a ZIP is validated against licensed states before proceeding, and `summary` is meant to be read back for correction. However, it omits how the returned question/options are shaped and any failure behavior, so it is useful but not complete.
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 call-loop instruction is front-loaded, which is good, but it is then repeated: 'call it until ready_to_quote is true' in paragraph one and 'Call it before each question and again after every answer, until ready_to_quote is true' in paragraph two. Five paragraphs for a single-question fetch is heavy, and the pacing rationale ('working people, often quoting on a phone') is motivational rather than operational.
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, return values need not be explained, and the description still covers the parts an agent needs: the 3-step workflow, state handling via `collected`, the two `stage` stretches and what each asks, ZIP licensing checks, and the commercial-auto boundary. Nothing essential for correct invocation is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and every parameter already carries a detailed description, so the baseline is 3. The description reinforces the `answered`/`collected` round-trip contract and the `stage` distinction, but this largely restates what the schema fields already say rather than adding new syntax or format detail.
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?
States a concrete verb and resource (returns the one question to put to the customer now, in their language, with options) and immediately positions itself in a workflow as 'Step 1 of 3'. It also names the siblings it is not (commercial_next_question for commercial auto, start_quote as the follow-on), so an agent can route without opening any schema.
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 when-to-use loop: 'Call it before each question and again after every answer, until ready_to_quote is true, then call start_quote.' It also gives exclusions and the alternative: a business-use vehicle is commercial auto and goes to commercial_next_question, while rideshare-only drivers stay here.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
other_carrier_questionsRetired: the other carriers' questionsARead-onlyInspect
Retired. Do not call it: carrier_questions asks every carrier's questions at once, and get_quote carries the firm prices in firm_prices.
Kept so an older conversation that reaches it is told where to go, with the link. It asks nothing and reads nothing.
| Name | Required | Description | Default |
|---|---|---|---|
| locale | Yes | The language the customer is writing in. Set it from their own messages rather than leaving the default: the estimate's notice comes back in this language, and a notice the customer cannot read discloses nothing. Sigo serves these two languages only. | |
| quote_id | Yes | The handle start_quote returned. | |
| answers_so_far | No | Ignored: nothing is carried here any more. |
Output Schema
| Name | Required | Description |
|---|---|---|
| note | Yes | What to do with these questions, in the customer's language. |
| preamble | Yes | Sigo's own words for the customer, to say as they are before the first question. Not one of the carrier's questions and not answered. Null when there is nothing to ask here. |
| next_step | Yes | Where the customer finishes. Theirs at any point, not only at the end. |
| questions | Yes | In the order the platform ranked them. |
| ask_together | Yes | Codes that can be put to the customer in one turn, grouped the way the carrier groups them. Ask each block as one message and send its answers together. A question with `depends_on` is in no block: it gets its own turn, after the one it hangs off. Empty when there is nothing to ask here. |
| can_answer_here | Yes | Always false: these questions are asked by carrier_questions now, once for every carrier. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare openWorldHint=true, implying external interaction, while the description says it 'asks nothing and reads nothing' and is retired. That directly contradicts the openWorld annotation and conflicts with the read-only-operation implication; per the rubric, a contradiction scores 1.
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 text is very short and front-loads the critical instruction: 'Retired. Do not call it.' Every sentence serves the legacy-routing purpose with no waste.
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 retired status and the presence of an output schema, an agent only needs routing information. The description provides the alternatives and explains the legacy-conversation context, so nothing necessary is missing.
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%, including descriptions for quote_id, locale, and answers_so_far. The description adds no parameter meaning beyond noting that answers_so_far is ignored, which the schema already states, so the baseline 3 applies.
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 states the tool is retired and explicitly says 'Do not call it,' then identifies the intended alternatives: carrier_questions and get_quote. This clearly distinguishes it from siblings and tells an agent what the tool is and is not for.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives explicit when-not-to-use guidance and names the replacement tools with their roles. An agent reaching this definition is told exactly where to go instead of invoking it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
resolve_application_linkRead a Sigo link the customer already hasARead-onlyInspect
Outside the three steps: for a customer who arrives with a Sigo link they already have.
Says what a Sigo link points at, how far that application has got, and the one thing the customer has to do next. Call it when someone shows up with a link — from an email, a text, or their own notes — and asks for help finishing.
Pass only the Sigo link or code they shared. It resolves the short link, the long one and a bare code.
It reads only: it opens nothing on the customer's behalf, and asking twice changes nothing. It reports no price, carrier or personal detail, because Sigo does not send any — whoever holds a link gets this same answer, so there is nothing here that identifies its owner. Say the message as given rather than composing one.
| Name | Required | Description | Default |
|---|---|---|---|
| locale | No | The language to write the returned `message` in: the customer's own, es or en. | es |
| pasted_link | Yes | Only the Sigo link or code the customer shared (a sigoseguros.com link or a short code), not the rest of their message. Stray punctuation around it is fine; do not guess at a link the customer did not provide. |
Output Schema
| Name | Required | Description |
|---|---|---|
| url | Yes | The link to hand back so the customer can continue, or null when nothing resolved. Use this URL rather than the one the customer pasted. |
| state | Yes | How far the application has got. Coarse on purpose. |
| message | Yes | What to tell the customer, already written in their language. Say this rather than composing your own: it is the only description of the application Sigo has checked, and it deliberately states no price, carrier or personal detail because none was read. |
| next_step | Yes | The single next action, as a value. `message` is the wording for it. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond readOnlyHint/destructiveHint it discloses that the call is idempotent ('asking twice changes nothing'), that it takes no action on the customer's behalf, and, without being asked, that no price, carrier or personal detail is returned because any link holder gets the same answer. That is genuinely useful behavioral context an agent could not infer from 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 purpose is front-loaded in the first sentence and each subsequent sentence carries distinct information (trigger, input, safety, output guidance). It is moderately long and slightly conversational, but no sentence is filler.
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 need not explain return values, and it covers the trigger, input format, and safety posture. Nothing an agent needs to call this correctly appears to be missing.
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 baseline is 3, but the description adds real meaning: it clarifies what to pass (only the link or bare code, not the surrounding message) and which formats are accepted (short link, long link, bare code). The locale parameter is left to 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 states a specific verb and resource — it resolves a pasted Sigo link and reports what it points at, how far the application has progressed, and the next step. It positions itself against the sibling quote-flow tools with 'Outside the three steps', so an agent can distinguish it from start_quote/get_quote without reading schemas.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives an explicit trigger: call it when a customer arrives with a link from an email, text, or notes and asks for help finishing. It also implicitly excludes the three-step flow. It stops short of naming a specific sibling tool as the alternative, so it is clear but not fully routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
start_quoteStart a car insurance quoteAInspect
Step 2 of 3: call it once, with the collected next_question returned when ready_to_quote was true. It returns a quote_id for get_quote. If it answers quote_in_progress, do not call it again: read the quote_id you already have. Retrying the same call, after a timeout say, is safe: while its rating runs, the retry starts no second one and answers quote_in_progress.
Asks Sigo's carriers for car insurance estimates. Carriers answer over tens of seconds, so this returns a quote_id straight away rather than waiting; read the prices with get_quote. Estimates are not binding: this does not select a policy, take payment or bind coverage. No browser is needed to get them: they come back in these tool calls, and the link in each one is where the customer continues if they want to buy.
Call it once the details are gathered. Gather them a step at a time in conversation — listing every field up front reads as a form and loses people before the first answer.
For a customer who already has a quote and wants something changed, pass that quote's id as revise_of instead of starting over: the same person re-quoted, not a second one. A call for a customer who already quoted today and is still at their first round revises that quote even without revise_of — the result says revised_from_quote: true — so a forgotten id never makes a second application.
The same call carries the second round. Once the customer has answered what next_question asks with stage: "second_round" — address, VIN, ownership and lienholder, licence status and months held, occupation, education, prior coverage, excluded drivers, and each driver's document number in drivers[].document.number — send them all here with revise_of, and the carriers price the quote again on what they now know.
The address the second round asks for is where the car is kept, and it is checked against the ZIP the quote is running on. They disagree, and the answer is to correct whichever one is wrong — never to move the customer onto a ZIP in a state the car is not kept in.
One quote at a time per customer. If their previous quote is still being answered, this fails with quote_in_progress and a poll_after_seconds: say so, read the earlier quote with get_quote when that time has passed, then ask for this one again with revise_of. Two asks at once ("the Civic and the Silverado") are run one after the other, and each result's asked_for says which is which.
Apart from arguments the schema rejects, a refusal comes back with a code, a message for the customer and a next_step for you, which says what to do next and which tool, if any, to call.
| Name | Required | Description | Default |
|---|---|---|---|
| Yes | Identifies the customer and is how Sigo reaches them about this quote. No phone number is collected here, so nothing can be called or texted from this channel — which is not the same as Sigo not calling: a customer who wants a call leaves their number in Sigo's own flow, through the link on their estimate, and an agent calls them. | ||
| locale | Yes | The language the customer is writing in. Set it from their own messages rather than leaving the default: the estimate's notice comes back in this language, and a notice the customer cannot read discloses nothing. Sigo serves these two languages only. | |
| address | No | Second round only. The street address where the car is kept overnight — street and number; the ZIP already gave the city and the state. It is checked against that ZIP, and an address somewhere else is refused rather than quoted: this is the field that decides which state the policy is rated in. Where they work is not it. | |
| drivers | Yes | ||
| vehicles | Yes | ||
| zip_code | Yes | The 5-digit ZIP code where the vehicle is kept. It determines the state. | |
| collected | Yes | The `collected` next_question returned once `ready_to_quote` was true. Required: it is the record that every question was put to the customer. A call without it, or with one that still has questions pending, is refused with `questions_not_finished` and creates nothing. | |
| revise_of | No | When the customer wants a quote they already have run again with something changed — another deductible, another coverage, a detail they gave wrong: pass that quote's `quote_id` here, with the full details including the change. It re-quotes the same person instead of making them a second one. Never invent this value, and never use it for a different customer. | |
| is_student | No | ||
| is_homeowner | No | ||
| correction_of | No | Only when a previous call failed with `data_not_accepted`: pass the `correction_of` it returned, together with the corrected details. The quote is retried on the same record instead of starting a second one for the same person. Never invent this value. | |
| uninsured_motorist | Yes | Whether to include uninsured-motorist protection — cover for when the other driver has no insurance. Ask it; it is the one add-on offered at this step and it changes the price. | |
| has_prior_insurance | Yes | Whether the customer currently has car insurance. | |
| prior_coverage_months | No | Second round only, and only for a customer who has insurance now. How long they have been covered: offer 6 months, 1 year, 3 years, 4 or more. | |
| prior_coverage_expiration | No | Second round only. YYYY-MM-DD, when the current policy ends. Today is accepted; a date already past is refused: confirm it with the customer, and if their coverage really did end, they have no prior insurance to send. |
Output Schema
| Name | Required | Description |
|---|---|---|
| state | Yes | |
| covers | Yes | |
| quotes | Yes | |
| status | Yes | |
| contact | Yes | |
| carriers | Yes | |
| problems | Yes | |
| quote_id | Yes | Pass this back to get_quote to read the result again. |
| asked_for | Yes | Label each answer with this when comparing two quotes for the same customer, so "con deducible de 1000" is matched to the quote that asked for it. |
| issued_by | Yes | |
| quoted_at | Yes | |
| expires_at | Yes | |
| application | Yes | |
| firm_prices | Yes | |
| pending_note | Yes | What to do while carriers are still answering, in the customer's language. Null once the list is final. |
| price_levers | Yes | |
| to_final_quote | Yes | |
| personal_use_note | Yes | Present when the customer said the vehicle is used for work. Say it with the prices: this quote is personal auto. Null when they said nothing about it, and then the subject is not raised. |
| poll_after_seconds | Yes | How long to wait before calling get_quote again. |
| revised_from_quote | Yes | True when this quote re-quoted the same customer: started with revise_of, or for a customer who already quoted today and was still at their first round. One person, one application, priced again. |
| more_carriers_pending | Yes | True when more carriers may still return a price; the list is not final. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well beyond the annotations: carriers take tens of seconds so the call returns a quote_id immediately, retries during rating start no second quote, estimates are non-binding with no policy selection/payment, and refusals return a code, customer message and next_step. The one-quote-at-a-time rule and the address-versus-ZIP refusal are side effects an agent would otherwise discover by failing.
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?
Front-loaded with the step number and the single-call rule, and every paragraph carries operational content. Some material is doubled — the quote_in_progress behaviour is explained both in paragraph one and in 'One quote at a time per customer', and the address/ZIP caution repeats the schema — but no sentence is pure filler.
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 15-parameter, 8-required, multi-round tool with an output schema, the description supplies the missing workflow layer: preconditions, the revise/correction reuse paths, the second-round batch, and the refusal contract. Return values are covered by the output schema, so omitting their shape is appropriate.
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?
With 73% schema coverage the schema already carries most parameter meaning, and the description still adds real semantics: which fields belong to the second round (address, VIN, ownership, lienholder, licence status, occupation, education, prior coverage, document number), that revise_of re-quotes the same person, and that collected is the completion record or the call is refused with questions_not_finished. It does not add syntax detail for the top-level required fields, which keeps it below a 5.
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?
States a specific verb and resource ('Asks Sigo's carriers for car insurance estimates') and immediately scopes it in a workflow ('Step 2 of 3'). It explicitly separates itself from neighbours: get_quote reads prices, next_question gathers fields, find_occupation supplies rater codes. An agent can pick this tool without opening any schema.
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?
Gives explicit when-to-call (once ready_to_quote was true, once details are gathered, one field at a time), when-not-to (do not retry on quote_in_progress; do not start over for a change — use revise_of; do not move a customer to a ZIP in another state), and named alternatives. The quote_in_progress / poll_after_seconds branch and the rideshare stop condition are both spelled out.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
submit_commercial_applicationSend a business's commercial auto request to SigoAInspect
Commercial auto, step 2 of 2: call it once, with the collected commercial_next_question returned when ready_to_submit was true. Do not call it again after it answers: a repeat is usually answered with the earlier request and already_received: true, but that is not guaranteed, and a second call can file a second request.
Sends the intake to Sigo, where a licensed agent reviews it and follows up by email. It is a request for a quote, not a quote: it returns no price, selects no policy, takes no payment and binds no coverage. Say message and disclaimer as written, and offer form_url with form_note for a customer who wants to add their vehicles and drivers now.
A refusal comes back with a code, a message for the customer and a next_step for you. One that says the request did not reach Sigo carries form_url: never tell the customer it was received.
| Name | Required | Description | Default |
|---|---|---|---|
| locale | Yes | The language the customer is writing in. Set it from their own messages: the questions come back in it, and the request is filed in it so the Sigo agent follows up in it. | |
| collected | Yes | The `collected` commercial_next_question returned when ready_to_submit was true. |
Output Schema
| Name | Required | Description |
|---|---|---|
| status | Yes | Sigo has the request. A Sigo agent follows up; nothing was quoted here. |
| message | Yes | What to tell the customer, as written. |
| form_url | Yes | The website's full commercial form, in the customer's language. |
| form_note | Yes | The line to give the customer with form_url. |
| reference | Yes | Sigo's reference for the request. Not a quote and not a policy number. |
| disclaimer | Yes | The notice every quote is subject to. Say it as written; it is the disclosure itself. |
| already_received | Yes | True when this business had already sent the same request: the earlier one is answered again, and no second one was filed. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly=false, idempotent=false, openWorld=true. The description goes well beyond them: it discloses that a repeat may return the earlier request with already_received:true but is not guaranteed, that a second call can file a duplicate request, that the process is human-reviewed with email follow-up, and that no price/policy/payment/binding occurs. It also describes refusal return shape and the form_url case.
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?
Front-loads the step framing and the single-call rule, then moves to effect, then to refusal handling. Dense but every sentence carries a load-bearing constraint; no filler.
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?
An output schema exists, yet the description still supplies the operational context an agent needs: sequencing, idempotency risk, what the customer should be told, and how refusals surface. Nothing material is missing for a two-parameter submission tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds genuine meaning beyond the schema by tying `collected` to a specific upstream state (the commercial_next_question returned when ready_to_submit was true) and by locating `locale` in the workflow. Minor added value over an already-complete 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?
States a specific verb and resource (sends the commercial auto intake to Sigo) and explicitly frames itself as 'step 2 of 2' with the trigger condition 'ready_to_submit was true'. This distinguishes it from the sibling commercial_next_question, which produces the input this tool consumes.
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?
Gives explicit when-to-use ('call it once, with the collected commercial_next_question returned when ready_to_submit was true') and when-not ('Do not call it again after it answers'), plus the failure mode of a repeat call. Nothing about invocation timing is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
1 tool update
- Changed
start_quote1 field changed- changed
Input schema / properties / email / patternPrevious value: -"^(?!\\.)(?!.*\\.\\.)([A-Za-z0-9_'+\\-\\.]*)[A-Za-z0-9_+-]@([A-Za-z0-9][A-Za-z0-9\\-]*\\.)+[A-Za-z]{2,}$"New value: +"^(?:[A-Za-z0-9_'+\\-]+\\.)*[A-Za-z0-9_'+\\-]*[A-Za-z0-9_+-]@(?:[A-Za-z0-9][A-Za-z0-9\\-]*\\.)+[A-Za-z]{2,}$"
7 tool updates
- Changed
answer_carrier_questions3 fields changed- changed
Input schema / properties / chosen_quote_id / descriptionPrevious value: -"The estimate the customer picked."New value: +"The estimate the customer picked. Left out on the four-carrier path, as at carrier_questions." - changed
Input schema / requiredPrevious value: -[ - "quote_id", - "chosen_quote_id", - "answers", - "locale" -]New value: +[ + "quote_id", + "answers", + "locale" +] - removed
Output schema / properties / quote_idRemoved value: -{ - "description": "Present once CoverCube's answers are filed: read the confirmed price with get_quote using this quote_id, which replaces the earlier one.", - "type": [ - "string", - "null" - ] -}
- Changed
answer_other_carrier_questions2 fields changed- changed
Input schema / properties / answers_so_far / descriptionPrevious value: -"The `answers_so_far` from the previous call, when there was one: it carries what the customer already answered, so only the new answers need to go in `answers`."New value: +"Ignored: nothing is carried here any more." - changed
Output schema / properties / filed / descriptionPrevious value: -"True once the whole pass is filed and the cheapest of the other carriers is selected."New value: +"Always false: nothing is filed here any more. answer_carrier_questions files the one pass."
- Changed
carrier_questions3 fields changed- changed
Input schema / properties / chosen_quote_id / descriptionPrevious value: -"The `quote_id` of the estimate the customer picked, from the list they were shown."New value: +"The `quote_id` of the estimate the customer picked, from the list they were shown. Leave it out when get_quote answered with a `firm_prices` block: there the questions are the same for every carrier." - changed
Input schema / requiredPrevious value: -[ - "quote_id", - "chosen_quote_id", - "locale" -]New value: +[ + "quote_id", + "locale" +] - changed
Output schema / properties / can_answer_here / descriptionPrevious value: -"False when there is nothing to ask here yet: the application is still missing details, or the carrier does not finish online in this state. Check `still_needed` to tell the two apart."New value: +"False when there is nothing to ask here: the application is still missing details, the carrier does not finish online in this state, or the answers were already filed. Check `still_needed` and `note` to tell them apart."
- Changed
get_quote4 fields changed- removed
Output schema / properties / cover_firstRemoved value: -{ - "anyOf": [ - { - "additionalProperties": false, - "properties": { - "chosen_quote_id": { - "description": "The one estimate's quote_id, to pass to carrier_questions. Null when there is none.", - "type": [ - "string", - "null" - ] - }, - "confirmed_price": { - "anyOf": [ - { - "additionalProperties": false, - "properties": { - "currency": { - "const": "USD", - "type": "string" - }, - "due_today": { - "type": "number" - }, - "monthly_payment": { - "type": "number" - }, - "total_for_term": { - "type": "number" - } - }, - "required": [ - "currency", - "due_today", - "monthly_payment", - "total_for_term" - ], - "type": "object" - }, - { - "type": "null" - } - ], - "description": "The carrier's confirmed amounts, once confirmed. Still subject to eligibility and state rules." - }, - "more_options_offered": { - "description": "True when Sigo offers to look at the other carriers beside a confirmed price. Offer it once; other_carrier_questions is how, and only if the customer wants to compare.", - "type": "boolean" - }, - "next_call": { - "description": "Exactly what to call next, with its arguments; null when nothing is.", - "type": [ - "string", - "null" - ] - }, - "note": { - "description": "What to tell the customer and do next, in their language.", - "type": "string" - }, - "poll_after_seconds": { - "anyOf": [ - { - "maximum": 9007199254740991, - "minimum": -9007199254740991, - "type": "integer" - }, - { - "type": "null" - } - ], - "description": "While confirming: how long to wait before get_quote again." - }, - "status": { - "description": "rating: carriers still answering. questions_pending: ask carrier_questions for the one estimate shown. handed_off: the answers are in and the carrier did not confirm here; give the customer next_step's link and stop. confirming: Sigo is confirming the price, read again. confirmed: the price is in confirmed_price and the customer pays in the link. declined / not_available: that option is not the answer; other_carrier_questions follows.", - "enum": [ - "rating", - "questions_pending", - "confirming", - "confirmed", - "declined", - "not_available", - "handed_off" - ], - "type": "string" - } - }, - "required": [ - "status", - "chosen_quote_id", - "confirmed_price", - "more_options_offered", - "poll_after_seconds", - "next_call", - "note" - ], - "type": "object" - }, - { - "type": "null" - } - ] -} - added
Output schema / properties / firm_pricesAdded value: +{ + "anyOf": [ + { + "additionalProperties": false, + "properties": { + "next_call": { + "description": "Exactly what to call next, with its arguments; null when nothing is.", + "type": [ + "string", + "null" + ] + }, + "note": { + "description": "What to tell the customer and do next, in their language.", + "type": "string" + }, + "options": { + "description": "The firm prices the customer may pay now, lowest today's payment first. Each is a carrier's confirmed price, still subject to underwriting, eligibility, and state filing, and bought only in the link.", + "items": { + "additionalProperties": false, + "properties": { + "carrier_name": { + "type": "string" + }, + "currency": { + "const": "USD", + "type": "string" + }, + "due_today": { + "description": "What the customer pays today, broker fee included.", + "type": "number" + }, + "excluded_people": { + "description": "How many people the carrier excluded from this price. Say so with the price when it is not zero; who they are is shown in the link, never here.", + "maximum": 9007199254740991, + "minimum": -9007199254740991, + "type": "integer" + }, + "installment_amount": { + "description": "Per instalment after today; null for pay-in-full.", + "type": [ + "number", + "null" + ] + }, + "number_of_installments": { + "maximum": 9007199254740991, + "minimum": -9007199254740991, + "type": "integer" + }, + "payment_method": { + "description": "The way of paying this price is valid on: card, ach or direct_bill. The customer confirms it in the link.", + "type": "string" + }, + "requires_autopay": { + "description": "True when this price is only available with automatic payments. Say so with the price; the customer accepts autopay in the link before paying it.", + "type": "boolean" + }, + "roadside_included": { + "description": "Whether roadside assistance is part of this price.", + "type": "boolean" + }, + "term_months": { + "anyOf": [ + { + "maximum": 9007199254740991, + "minimum": -9007199254740991, + "type": "integer" + }, + { + "type": "null" + } + ] + }, + "total_for_term": { + "description": "Today's payment plus the instalments. Stated so it is not worked out.", + "type": "number" + } + }, + "required": [ + "carrier_name", + "currency", + "due_today", + "installment_amount", + "number_of_installments", + "total_for_term", + "payment_method", + "term_months", + "roadside_included", + "requires_autopay", + "excluded_people" + ], + "type": "object" + }, + "type": "array" + }, + "poll_after_seconds": { + "anyOf": [ + { + "maximum": 9007199254740991, + "minimum": -9007199254740991, + "type": "integer" + }, + { + "type": "null" + } + ], + "description": "While pricing: how long to wait before get_quote again." + }, + "status": { + "description": "rating: carriers still answering. questions_pending: ask carrier_questions with this quote_id and no chosen_quote_id. pricing: the carriers are confirming; options holds what has landed, read again after poll_after_seconds. ready: every price is in options and the customer chooses and pays in the link. agent: no carrier confirmed a price online; a Sigo agent takes it.", + "enum": [ + "rating", + "questions_pending", + "pricing", + "ready", + "agent" + ], + "type": "string" + } + }, + "required": [ + "status", + "options", + "poll_after_seconds", + "next_call", + "note" + ], + "type": "object" + }, + { + "type": "null" + } + ] +} - changed
Output schema / properties / to_final_quote / properties / next_call / descriptionPrevious value: -"Exactly what to call next, with its arguments: `next_question` with stage second_round while the application is incomplete; `carrier_questions` with `quote_id` (this quote) and `chosen_quote_id` (the `quote_id` of the estimate the customer picked) once it is. Null before there are prices."New value: +"Exactly what to call next, with its arguments: `next_question` with stage second_round while the application is incomplete; `carrier_questions` with `quote_id` (this quote) and `chosen_quote_id` (the `quote_id` of the estimate the customer picked) once it is, or with no `chosen_quote_id` when `firm_prices` is present. Null before there are prices." - changed
Output schema / requiredPrevious value: -[ - "quote_id", - "status", - "more_carriers_pending", - "poll_after_seconds", - "pending_note", - "to_final_quote", - "cover_first", - "application", - "state", - "quoted_at", - "expires_at", - "quotes", - "problems", - "contact", - "covers", - "asked_for", - "revised_from_quote", - "price_levers", - "personal_use_note", - "carriers", - "issued_by" -]New value: +[ + "quote_id", + "status", + "more_carriers_pending", + "poll_after_seconds", + "pending_note", + "to_final_quote", + "firm_prices", + "application", + "state", + "quoted_at", + "expires_at", + "quotes", + "problems", + "contact", + "covers", + "asked_for", + "revised_from_quote", + "price_levers", + "personal_use_note", + "carriers", + "issued_by" +]
- Changed
next_question2 fields changed- added
Input schema / properties / answered / properties / annual_mileageAdded value: +{ + "description": "Second round, where asked. The whole number the customer gave or picked, sent with `annual_mileage_settled` so the summary can read it back; each vehicle's own figure goes to `start_quote` in `vehicles[].annual_mileage`.", + "maximum": 50000, + "minimum": 1000, + "type": "integer" +} - added
Input schema / properties / answered / properties / annual_mileage_settledAdded value: +{ + "const": true, + "description": "Second round, where asked. Send once every vehicle has its miles per year.", + "type": "boolean" +}
- Changed
other_carrier_questions2 fields changed- changed
Input schema / properties / answers_so_far / descriptionPrevious value: -"The `answers_so_far` answer_carrier_questions handed back when the first option ended, when there was one: what the customer already answered is then not asked again."New value: +"Ignored: nothing is carried here any more." - changed
Output schema / properties / can_answer_here / descriptionPrevious value: -"False when there is nothing to ask here: nobody priced the customer, and a Sigo agent takes it."New value: +"Always false: these questions are asked by carrier_questions now, once for every carrier."
- Changed
start_quote5 fields changed- added
Input schema / properties / vehicles / items / properties / annual_mileageAdded value: +{ + "anyOf": [ + { + "maximum": 50000, + "minimum": 1000, + "type": "integer" + }, + { + "type": "null" + } + ], + "description": "Second round only, and only where next_question asked it (California). The customer's own estimate of miles per year, as a whole number: the figure they said or the round number they picked, never a range converted by the agent. The carrier has them attest to it." +} - removed
Output schema / properties / cover_firstRemoved value: -{ - "anyOf": [ - { - "additionalProperties": false, - "properties": { - "chosen_quote_id": { - "description": "The one estimate's quote_id, to pass to carrier_questions. Null when there is none.", - "type": [ - "string", - "null" - ] - }, - "confirmed_price": { - "anyOf": [ - { - "additionalProperties": false, - "properties": { - "currency": { - "const": "USD", - "type": "string" - }, - "due_today": { - "type": "number" - }, - "monthly_payment": { - "type": "number" - }, - "total_for_term": { - "type": "number" - } - }, - "required": [ - "currency", - "due_today", - "monthly_payment", - "total_for_term" - ], - "type": "object" - }, - { - "type": "null" - } - ], - "description": "The carrier's confirmed amounts, once confirmed. Still subject to eligibility and state rules." - }, - "more_options_offered": { - "description": "True when Sigo offers to look at the other carriers beside a confirmed price. Offer it once; other_carrier_questions is how, and only if the customer wants to compare.", - "type": "boolean" - }, - "next_call": { - "description": "Exactly what to call next, with its arguments; null when nothing is.", - "type": [ - "string", - "null" - ] - }, - "note": { - "description": "What to tell the customer and do next, in their language.", - "type": "string" - }, - "poll_after_seconds": { - "anyOf": [ - { - "maximum": 9007199254740991, - "minimum": -9007199254740991, - "type": "integer" - }, - { - "type": "null" - } - ], - "description": "While confirming: how long to wait before get_quote again." - }, - "status": { - "description": "rating: carriers still answering. questions_pending: ask carrier_questions for the one estimate shown. handed_off: the answers are in and the carrier did not confirm here; give the customer next_step's link and stop. confirming: Sigo is confirming the price, read again. confirmed: the price is in confirmed_price and the customer pays in the link. declined / not_available: that option is not the answer; other_carrier_questions follows.", - "enum": [ - "rating", - "questions_pending", - "confirming", - "confirmed", - "declined", - "not_available", - "handed_off" - ], - "type": "string" - } - }, - "required": [ - "status", - "chosen_quote_id", - "confirmed_price", - "more_options_offered", - "poll_after_seconds", - "next_call", - "note" - ], - "type": "object" - }, - { - "type": "null" - } - ] -} - added
Output schema / properties / firm_pricesAdded value: +{ + "anyOf": [ + { + "additionalProperties": false, + "properties": { + "next_call": { + "description": "Exactly what to call next, with its arguments; null when nothing is.", + "type": [ + "string", + "null" + ] + }, + "note": { + "description": "What to tell the customer and do next, in their language.", + "type": "string" + }, + "options": { + "description": "The firm prices the customer may pay now, lowest today's payment first. Each is a carrier's confirmed price, still subject to underwriting, eligibility, and state filing, and bought only in the link.", + "items": { + "additionalProperties": false, + "properties": { + "carrier_name": { + "type": "string" + }, + "currency": { + "const": "USD", + "type": "string" + }, + "due_today": { + "description": "What the customer pays today, broker fee included.", + "type": "number" + }, + "excluded_people": { + "description": "How many people the carrier excluded from this price. Say so with the price when it is not zero; who they are is shown in the link, never here.", + "maximum": 9007199254740991, + "minimum": -9007199254740991, + "type": "integer" + }, + "installment_amount": { + "description": "Per instalment after today; null for pay-in-full.", + "type": [ + "number", + "null" + ] + }, + "number_of_installments": { + "maximum": 9007199254740991, + "minimum": -9007199254740991, + "type": "integer" + }, + "payment_method": { + "description": "The way of paying this price is valid on: card, ach or direct_bill. The customer confirms it in the link.", + "type": "string" + }, + "requires_autopay": { + "description": "True when this price is only available with automatic payments. Say so with the price; the customer accepts autopay in the link before paying it.", + "type": "boolean" + }, + "roadside_included": { + "description": "Whether roadside assistance is part of this price.", + "type": "boolean" + }, + "term_months": { + "anyOf": [ + { + "maximum": 9007199254740991, + "minimum": -9007199254740991, + "type": "integer" + }, + { + "type": "null" + } + ] + }, + "total_for_term": { + "description": "Today's payment plus the instalments. Stated so it is not worked out.", + "type": "number" + } + }, + "required": [ + "carrier_name", + "currency", + "due_today", + "installment_amount", + "number_of_installments", + "total_for_term", + "payment_method", + "term_months", + "roadside_included", + "requires_autopay", + "excluded_people" + ], + "type": "object" + }, + "type": "array" + }, + "poll_after_seconds": { + "anyOf": [ + { + "maximum": 9007199254740991, + "minimum": -9007199254740991, + "type": "integer" + }, + { + "type": "null" + } + ], + "description": "While pricing: how long to wait before get_quote again." + }, + "status": { + "description": "rating: carriers still answering. questions_pending: ask carrier_questions with this quote_id and no chosen_quote_id. pricing: the carriers are confirming; options holds what has landed, read again after poll_after_seconds. ready: every price is in options and the customer chooses and pays in the link. agent: no carrier confirmed a price online; a Sigo agent takes it.", + "enum": [ + "rating", + "questions_pending", + "pricing", + "ready", + "agent" + ], + "type": "string" + } + }, + "required": [ + "status", + "options", + "poll_after_seconds", + "next_call", + "note" + ], + "type": "object" + }, + { + "type": "null" + } + ] +} - changed
Output schema / properties / to_final_quote / properties / next_call / descriptionPrevious value: -"Exactly what to call next, with its arguments: `next_question` with stage second_round while the application is incomplete; `carrier_questions` with `quote_id` (this quote) and `chosen_quote_id` (the `quote_id` of the estimate the customer picked) once it is. Null before there are prices."New value: +"Exactly what to call next, with its arguments: `next_question` with stage second_round while the application is incomplete; `carrier_questions` with `quote_id` (this quote) and `chosen_quote_id` (the `quote_id` of the estimate the customer picked) once it is, or with no `chosen_quote_id` when `firm_prices` is present. Null before there are prices." - changed
Output schema / requiredPrevious value: -[ - "quote_id", - "status", - "more_carriers_pending", - "poll_after_seconds", - "pending_note", - "to_final_quote", - "cover_first", - "application", - "state", - "quoted_at", - "expires_at", - "quotes", - "problems", - "contact", - "covers", - "asked_for", - "revised_from_quote", - "price_levers", - "personal_use_note", - "carriers", - "issued_by" -]New value: +[ + "quote_id", + "status", + "more_carriers_pending", + "poll_after_seconds", + "pending_note", + "to_final_quote", + "firm_prices", + "application", + "state", + "quoted_at", + "expires_at", + "quotes", + "problems", + "contact", + "covers", + "asked_for", + "revised_from_quote", + "price_levers", + "personal_use_note", + "carriers", + "issued_by" +]
2 tool updates
- Added
commercial_next_question - Added
submit_commercial_application
4 tool updates
- Changed
answer_carrier_questions1 field changed- added
Output schema / properties / quote_idAdded value: +{ + "description": "Present once CoverCube's answers are filed: read the confirmed price with get_quote using this quote_id, which replaces the earlier one.", + "type": [ + "string", + "null" + ] +}
- Changed
get_quote1 field changed- changed
Output schema / properties / cover_first / anyOfPrevious value: -[ - { - "additionalProperties": false, - "properties": { - "chosen_quote_id": { - "description": "The one estimate's quote_id, to pass to carrier_questions. Null when there is none.", - "type": [ - "string", - "null" - ] - }, - "confirmed_price": { - "anyOf": [ - { - "additionalProperties": false, - "properties": { - "currency": { - "const": "USD", - "type": "string" - }, - "due_today": { - "type": "number" - }, - "monthly_payment": { - "type": "number" - }, - "total_for_term": { - "type": "number" - } - }, - "required": [ - "currency", - "due_today", - "monthly_payment", - "total_for_term" - ], - "type": "object" - }, - { - "type": "null" - } - ], - "description": "The carrier's confirmed amounts, once confirmed. Still subject to eligibility and state rules." - }, - "more_options_offered": { - "description": "True when Sigo offers to look at the other carriers beside a confirmed price. Offer it once; other_carrier_questions is how, and only if the customer wants to compare.", - "type": "boolean" - }, - "next_call": { - "description": "Exactly what to call next, with its arguments; null when nothing is.", - "type": [ - "string", - "null" - ] - }, - "note": { - "description": "What to tell the customer and do next, in their language.", - "type": "string" - }, - "poll_after_seconds": { - "anyOf": [ - { - "maximum": 9007199254740991, - "minimum": -9007199254740991, - "type": "integer" - }, - { - "type": "null" - } - ], - "description": "While confirming: how long to wait before get_quote again." - }, - "status": { - "description": "rating: carriers still answering. questions_pending: ask carrier_questions for the one estimate shown. confirming: Sigo is confirming the price, read again. confirmed: the price is in confirmed_price and the customer pays in the link. declined / not_available: that option is not the answer; other_carrier_questions follows.", - "enum": [ - "rating", - "questions_pending", - "confirming", - "confirmed", - "declined", - "not_available" - ], - "type": "string" - } - }, - "required": [ - "status", - "chosen_quote_id", - "confirmed_price", - "more_options_offered", - "poll_after_seconds", - "next_call", - "note" - ], - "type": "object" - }, - { - "type": "null" - } -]New value: +[ + { + "additionalProperties": false, + "properties": { + "chosen_quote_id": { + "description": "The one estimate's quote_id, to pass to carrier_questions. Null when there is none.", + "type": [ + "string", + "null" + ] + }, + "confirmed_price": { + "anyOf": [ + { + "additionalProperties": false, + "properties": { + "currency": { + "const": "USD", + "type": "string" + }, + "due_today": { + "type": "number" + }, + "monthly_payment": { + "type": "number" + }, + "total_for_term": { + "type": "number" + } + }, + "required": [ + "currency", + "due_today", + "monthly_payment", + "total_for_term" + ], + "type": "object" + }, + { + "type": "null" + } + ], + "description": "The carrier's confirmed amounts, once confirmed. Still subject to eligibility and state rules." + }, + "more_options_offered": { + "description": "True when Sigo offers to look at the other carriers beside a confirmed price. Offer it once; other_carrier_questions is how, and only if the customer wants to compare.", + "type": "boolean" + }, + "next_call": { + "description": "Exactly what to call next, with its arguments; null when nothing is.", + "type": [ + "string", + "null" + ] + }, + "note": { + "description": "What to tell the customer and do next, in their language.", + "type": "string" + }, + "poll_after_seconds": { + "anyOf": [ + { + "maximum": 9007199254740991, + "minimum": -9007199254740991, + "type": "integer" + }, + { + "type": "null" + } + ], + "description": "While confirming: how long to wait before get_quote again." + }, + "status": { + "description": "rating: carriers still answering. questions_pending: ask carrier_questions for the one estimate shown. handed_off: the answers are in and the carrier did not confirm here; give the customer next_step's link and stop. confirming: Sigo is confirming the price, read again. confirmed: the price is in confirmed_price and the customer pays in the link. declined / not_available: that option is not the answer; other_carrier_questions follows.", + "enum": [ + "rating", + "questions_pending", + "confirming", + "confirmed", + "declined", + "not_available", + "handed_off" + ], + "type": "string" + } + }, + "required": [ + "status", + "chosen_quote_id", + "confirmed_price", + "more_options_offered", + "poll_after_seconds", + "next_call", + "note" + ], + "type": "object" + }, + { + "type": "null" + } +]
- Changed
next_question2 fields changed- added
Input schema / properties / answered / properties / document_number_settledAdded value: +{ + "const": true, + "description": "Second round. Send once every driver who is not excluded has given their document's number.", + "type": "boolean" +} - changed
Input schema / properties / answered / properties / document_type / descriptionPrevious value: -"Which of the six it is, sent with `document_settled`, so the summary can read it back."New value: +"Which of the six it is, sent with `document_settled`, so the summary can read it back. Never the number: that goes to `start_quote` only."
- Changed
start_quote2 fields changed- changed
Input schema / properties / drivers / items / properties / document / anyOfPrevious value: -[ - { - "additionalProperties": false, - "properties": { - "type": { - "description": "Offer all six. A customer without a US licence is quotable on a foreign licence, a consular ID (matrícula) or a passport, and offering fewer reads as being turned away. None of the six is a learner permit, and the type on its own is never read as a full licence: a permit holder is recorded with the type of the document they carry and with `license_status: \"learner-permit\"`, which is what the rater prices as a permit.", - "enum": [ - "us_license", - "foreign_license", - "us_id", - "foreign_id", - "consular_id", - "passport" - ], - "type": "string" - } - }, - "required": [ - "type" - ], - "type": "object" - }, - { - "type": "null" - } -]New value: +[ + { + "additionalProperties": false, + "properties": { + "number": { + "anyOf": [ + { + "maxLength": 13, + "type": "string" + }, + { + "type": "null" + } + ], + "description": "Second round only, as on sigoseguros.com: required there for every driver who is not excluded, and dropped if sent on a first quote. A Texas licence is 7 or 8 digits, a California one 1 letter and 7 digits, a Florida one 1 letter and 12 digits; any other is up to 12 characters." + }, + "type": { + "description": "Offer all six. A customer without a US licence is quotable on a foreign licence, a consular ID (matrícula) or a passport, and offering fewer reads as being turned away. None of the six is a learner permit, and the type on its own is never read as a full licence: a permit holder is recorded with the type of the document they carry and with `license_status: \"learner-permit\"`, which is what the rater prices as a permit.", + "enum": [ + "us_license", + "foreign_license", + "us_id", + "foreign_id", + "consular_id", + "passport" + ], + "type": "string" + } + }, + "required": [ + "type" + ], + "type": "object" + }, + { + "type": "null" + } +] - changed
Output schema / properties / cover_first / anyOfPrevious value: -[ - { - "additionalProperties": false, - "properties": { - "chosen_quote_id": { - "description": "The one estimate's quote_id, to pass to carrier_questions. Null when there is none.", - "type": [ - "string", - "null" - ] - }, - "confirmed_price": { - "anyOf": [ - { - "additionalProperties": false, - "properties": { - "currency": { - "const": "USD", - "type": "string" - }, - "due_today": { - "type": "number" - }, - "monthly_payment": { - "type": "number" - }, - "total_for_term": { - "type": "number" - } - }, - "required": [ - "currency", - "due_today", - "monthly_payment", - "total_for_term" - ], - "type": "object" - }, - { - "type": "null" - } - ], - "description": "The carrier's confirmed amounts, once confirmed. Still subject to eligibility and state rules." - }, - "more_options_offered": { - "description": "True when Sigo offers to look at the other carriers beside a confirmed price. Offer it once; other_carrier_questions is how, and only if the customer wants to compare.", - "type": "boolean" - }, - "next_call": { - "description": "Exactly what to call next, with its arguments; null when nothing is.", - "type": [ - "string", - "null" - ] - }, - "note": { - "description": "What to tell the customer and do next, in their language.", - "type": "string" - }, - "poll_after_seconds": { - "anyOf": [ - { - "maximum": 9007199254740991, - "minimum": -9007199254740991, - "type": "integer" - }, - { - "type": "null" - } - ], - "description": "While confirming: how long to wait before get_quote again." - }, - "status": { - "description": "rating: carriers still answering. questions_pending: ask carrier_questions for the one estimate shown. confirming: Sigo is confirming the price, read again. confirmed: the price is in confirmed_price and the customer pays in the link. declined / not_available: that option is not the answer; other_carrier_questions follows.", - "enum": [ - "rating", - "questions_pending", - "confirming", - "confirmed", - "declined", - "not_available" - ], - "type": "string" - } - }, - "required": [ - "status", - "chosen_quote_id", - "confirmed_price", - "more_options_offered", - "poll_after_seconds", - "next_call", - "note" - ], - "type": "object" - }, - { - "type": "null" - } -]New value: +[ + { + "additionalProperties": false, + "properties": { + "chosen_quote_id": { + "description": "The one estimate's quote_id, to pass to carrier_questions. Null when there is none.", + "type": [ + "string", + "null" + ] + }, + "confirmed_price": { + "anyOf": [ + { + "additionalProperties": false, + "properties": { + "currency": { + "const": "USD", + "type": "string" + }, + "due_today": { + "type": "number" + }, + "monthly_payment": { + "type": "number" + }, + "total_for_term": { + "type": "number" + } + }, + "required": [ + "currency", + "due_today", + "monthly_payment", + "total_for_term" + ], + "type": "object" + }, + { + "type": "null" + } + ], + "description": "The carrier's confirmed amounts, once confirmed. Still subject to eligibility and state rules." + }, + "more_options_offered": { + "description": "True when Sigo offers to look at the other carriers beside a confirmed price. Offer it once; other_carrier_questions is how, and only if the customer wants to compare.", + "type": "boolean" + }, + "next_call": { + "description": "Exactly what to call next, with its arguments; null when nothing is.", + "type": [ + "string", + "null" + ] + }, + "note": { + "description": "What to tell the customer and do next, in their language.", + "type": "string" + }, + "poll_after_seconds": { + "anyOf": [ + { + "maximum": 9007199254740991, + "minimum": -9007199254740991, + "type": "integer" + }, + { + "type": "null" + } + ], + "description": "While confirming: how long to wait before get_quote again." + }, + "status": { + "description": "rating: carriers still answering. questions_pending: ask carrier_questions for the one estimate shown. handed_off: the answers are in and the carrier did not confirm here; give the customer next_step's link and stop. confirming: Sigo is confirming the price, read again. confirmed: the price is in confirmed_price and the customer pays in the link. declined / not_available: that option is not the answer; other_carrier_questions follows.", + "enum": [ + "rating", + "questions_pending", + "confirming", + "confirmed", + "declined", + "not_available", + "handed_off" + ], + "type": "string" + } + }, + "required": [ + "status", + "chosen_quote_id", + "confirmed_price", + "more_options_offered", + "poll_after_seconds", + "next_call", + "note" + ], + "type": "object" + }, + { + "type": "null" + } +]
3 tool updates
- Changed
next_question2 fields changed- removed
Input schema / properties / answered / properties / document_number_settledRemoved value: -{ - "const": true, - "description": "Second round. Send once every driver who is not excluded has given their document's number.", - "type": "boolean" -} - changed
Input schema / properties / answered / properties / document_type / descriptionPrevious value: -"Which of the six it is, sent with `document_settled`, so the summary can read it back. Never the number: that goes to `start_quote` only."New value: +"Which of the six it is, sent with `document_settled`, so the summary can read it back."
- Changed
resolve_application_link5 fields changed- added
Input schema / properties / locale / defaultAdded value: +"es" - changed
Input schema / properties / locale / descriptionPrevious value: -"The language the customer is writing in. Set it from their own messages rather than leaving the default: the estimate's notice comes back in this language, and a notice the customer cannot read discloses nothing. Sigo serves these two languages only."New value: +"The language to write the returned `message` in: the customer's own, es or en." - changed
Input schema / properties / pasted_link / descriptionPrevious value: -"The link or code the customer gave, exactly as they wrote it — surrounding words and punctuation are fine. Do not clean it up or guess at a link the customer did not provide."New value: +"Only the Sigo link or code the customer shared (a sigoseguros.com link or a short code), not the rest of their message. Stray punctuation around it is fine; do not guess at a link the customer did not provide." - changed
Input schema / properties / pasted_link / maxLengthPrevious value: -2048New value: +512 - changed
Input schema / requiredPrevious value: -[ - "pasted_link", - "locale" -]New value: +[ + "pasted_link" +]
- Changed
start_quote1 field changed- changed
Input schema / properties / drivers / items / properties / document / anyOfPrevious value: -[ - { - "additionalProperties": false, - "properties": { - "number": { - "anyOf": [ - { - "maxLength": 30, - "type": "string" - }, - { - "type": "null" - } - ], - "description": "Optional on a first quote. The second round asks for it, as the web does, and the carrier's questions do not open until every driver who is not excluded has it." - }, - "type": { - "description": "Offer all six. A customer without a US licence is quotable on a foreign licence, a consular ID (matrícula) or a passport, and offering fewer reads as being turned away. None of the six is a learner permit, and the type on its own is never read as a full licence: a permit holder is recorded with the type of the document they carry and with `license_status: \"learner-permit\"`, which is what the rater prices as a permit.", - "enum": [ - "us_license", - "foreign_license", - "us_id", - "foreign_id", - "consular_id", - "passport" - ], - "type": "string" - } - }, - "required": [ - "type" - ], - "type": "object" - }, - { - "type": "null" - } -]New value: +[ + { + "additionalProperties": false, + "properties": { + "type": { + "description": "Offer all six. A customer without a US licence is quotable on a foreign licence, a consular ID (matrícula) or a passport, and offering fewer reads as being turned away. None of the six is a learner permit, and the type on its own is never read as a full licence: a permit holder is recorded with the type of the document they carry and with `license_status: \"learner-permit\"`, which is what the rater prices as a permit.", + "enum": [ + "us_license", + "foreign_license", + "us_id", + "foreign_id", + "consular_id", + "passport" + ], + "type": "string" + } + }, + "required": [ + "type" + ], + "type": "object" + }, + { + "type": "null" + } +]
5 tool updates
- Changed
answer_carrier_questions2 fields changed- added
Output schema / properties / next_callAdded value: +{ + "description": "Exactly what to call next, with its arguments, when something follows here; null otherwise.", + "type": [ + "string", + "null" + ] +} - changed
Output schema / requiredPrevious value: -[ - "answered", - "filed", - "still_needed", - "answers_so_far", - "note", - "next_step" -]New value: +[ + "answered", + "filed", + "still_needed", + "answers_so_far", + "note", + "next_call", + "next_step" +]
- Added
answer_other_carrier_questions - Changed
get_quote2 fields changed- added
Output schema / properties / cover_firstAdded value: +{ + "anyOf": [ + { + "additionalProperties": false, + "properties": { + "chosen_quote_id": { + "description": "The one estimate's quote_id, to pass to carrier_questions. Null when there is none.", + "type": [ + "string", + "null" + ] + }, + "confirmed_price": { + "anyOf": [ + { + "additionalProperties": false, + "properties": { + "currency": { + "const": "USD", + "type": "string" + }, + "due_today": { + "type": "number" + }, + "monthly_payment": { + "type": "number" + }, + "total_for_term": { + "type": "number" + } + }, + "required": [ + "currency", + "due_today", + "monthly_payment", + "total_for_term" + ], + "type": "object" + }, + { + "type": "null" + } + ], + "description": "The carrier's confirmed amounts, once confirmed. Still subject to eligibility and state rules." + }, + "more_options_offered": { + "description": "True when Sigo offers to look at the other carriers beside a confirmed price. Offer it once; other_carrier_questions is how, and only if the customer wants to compare.", + "type": "boolean" + }, + "next_call": { + "description": "Exactly what to call next, with its arguments; null when nothing is.", + "type": [ + "string", + "null" + ] + }, + "note": { + "description": "What to tell the customer and do next, in their language.", + "type": "string" + }, + "poll_after_seconds": { + "anyOf": [ + { + "maximum": 9007199254740991, + "minimum": -9007199254740991, + "type": "integer" + }, + { + "type": "null" + } + ], + "description": "While confirming: how long to wait before get_quote again." + }, + "status": { + "description": "rating: carriers still answering. questions_pending: ask carrier_questions for the one estimate shown. confirming: Sigo is confirming the price, read again. confirmed: the price is in confirmed_price and the customer pays in the link. declined / not_available: that option is not the answer; other_carrier_questions follows.", + "enum": [ + "rating", + "questions_pending", + "confirming", + "confirmed", + "declined", + "not_available" + ], + "type": "string" + } + }, + "required": [ + "status", + "chosen_quote_id", + "confirmed_price", + "more_options_offered", + "poll_after_seconds", + "next_call", + "note" + ], + "type": "object" + }, + { + "type": "null" + } + ] +} - changed
Output schema / requiredPrevious value: -[ - "quote_id", - "status", - "more_carriers_pending", - "poll_after_seconds", - "pending_note", - "to_final_quote", - "application", - "state", - "quoted_at", - "expires_at", - "quotes", - "problems", - "contact", - "covers", - "asked_for", - "revised_from_quote", - "price_levers", - "personal_use_note", - "carriers", - "issued_by" -]New value: +[ + "quote_id", + "status", + "more_carriers_pending", + "poll_after_seconds", + "pending_note", + "to_final_quote", + "cover_first", + "application", + "state", + "quoted_at", + "expires_at", + "quotes", + "problems", + "contact", + "covers", + "asked_for", + "revised_from_quote", + "price_levers", + "personal_use_note", + "carriers", + "issued_by" +]
- Added
other_carrier_questions - Changed
start_quote4 fields changed- removed
Input schema / properties / vehicles / items / properties / make / patternRemoved value: -"^[\\p{L}\\p{N} .,'\\-/]+$" - removed
Input schema / properties / vehicles / items / properties / model / patternRemoved value: -"^[\\p{L}\\p{N} .,'\\-/]+$" - added
Output schema / properties / cover_firstAdded value: +{ + "anyOf": [ + { + "additionalProperties": false, + "properties": { + "chosen_quote_id": { + "description": "The one estimate's quote_id, to pass to carrier_questions. Null when there is none.", + "type": [ + "string", + "null" + ] + }, + "confirmed_price": { + "anyOf": [ + { + "additionalProperties": false, + "properties": { + "currency": { + "const": "USD", + "type": "string" + }, + "due_today": { + "type": "number" + }, + "monthly_payment": { + "type": "number" + }, + "total_for_term": { + "type": "number" + } + }, + "required": [ + "currency", + "due_today", + "monthly_payment", + "total_for_term" + ], + "type": "object" + }, + { + "type": "null" + } + ], + "description": "The carrier's confirmed amounts, once confirmed. Still subject to eligibility and state rules." + }, + "more_options_offered": { + "description": "True when Sigo offers to look at the other carriers beside a confirmed price. Offer it once; other_carrier_questions is how, and only if the customer wants to compare.", + "type": "boolean" + }, + "next_call": { + "description": "Exactly what to call next, with its arguments; null when nothing is.", + "type": [ + "string", + "null" + ] + }, + "note": { + "description": "What to tell the customer and do next, in their language.", + "type": "string" + }, + "poll_after_seconds": { + "anyOf": [ + { + "maximum": 9007199254740991, + "minimum": -9007199254740991, + "type": "integer" + }, + { + "type": "null" + } + ], + "description": "While confirming: how long to wait before get_quote again." + }, + "status": { + "description": "rating: carriers still answering. questions_pending: ask carrier_questions for the one estimate shown. confirming: Sigo is confirming the price, read again. confirmed: the price is in confirmed_price and the customer pays in the link. declined / not_available: that option is not the answer; other_carrier_questions follows.", + "enum": [ + "rating", + "questions_pending", + "confirming", + "confirmed", + "declined", + "not_available" + ], + "type": "string" + } + }, + "required": [ + "status", + "chosen_quote_id", + "confirmed_price", + "more_options_offered", + "poll_after_seconds", + "next_call", + "note" + ], + "type": "object" + }, + { + "type": "null" + } + ] +} - changed
Output schema / requiredPrevious value: -[ - "quote_id", - "status", - "more_carriers_pending", - "poll_after_seconds", - "pending_note", - "to_final_quote", - "application", - "state", - "quoted_at", - "expires_at", - "quotes", - "problems", - "contact", - "covers", - "asked_for", - "revised_from_quote", - "price_levers", - "personal_use_note", - "carriers", - "issued_by" -]New value: +[ + "quote_id", + "status", + "more_carriers_pending", + "poll_after_seconds", + "pending_note", + "to_final_quote", + "cover_first", + "application", + "state", + "quoted_at", + "expires_at", + "quotes", + "problems", + "contact", + "covers", + "asked_for", + "revised_from_quote", + "price_levers", + "personal_use_note", + "carriers", + "issued_by" +]
5 tool updates
- Changed
answer_carrier_questions2 fields changed- removed
Output schema / properties / next_callRemoved value: -{ - "description": "Exactly what to call next, with its arguments, when something follows here; null otherwise.", - "type": [ - "string", - "null" - ] -} - changed
Output schema / requiredPrevious value: -[ - "answered", - "filed", - "still_needed", - "answers_so_far", - "note", - "next_call", - "next_step" -]New value: +[ + "answered", + "filed", + "still_needed", + "answers_so_far", + "note", + "next_step" +]
- Removed
answer_other_carrier_questions - Changed
get_quote2 fields changed- removed
Output schema / properties / cover_firstRemoved value: -{ - "anyOf": [ - { - "additionalProperties": false, - "properties": { - "chosen_quote_id": { - "description": "The one estimate's quote_id, to pass to carrier_questions. Null when there is none.", - "type": [ - "string", - "null" - ] - }, - "confirmed_price": { - "anyOf": [ - { - "additionalProperties": false, - "properties": { - "currency": { - "const": "USD", - "type": "string" - }, - "due_today": { - "type": "number" - }, - "monthly_payment": { - "type": "number" - }, - "total_for_term": { - "type": "number" - } - }, - "required": [ - "currency", - "due_today", - "monthly_payment", - "total_for_term" - ], - "type": "object" - }, - { - "type": "null" - } - ], - "description": "The carrier's confirmed amounts, once confirmed. Still subject to eligibility and state rules." - }, - "more_options_offered": { - "description": "True when Sigo offers to look at the other carriers beside a confirmed price. Offer it once; other_carrier_questions is how, and only if the customer wants to compare.", - "type": "boolean" - }, - "next_call": { - "description": "Exactly what to call next, with its arguments; null when nothing is.", - "type": [ - "string", - "null" - ] - }, - "note": { - "description": "What to tell the customer and do next, in their language.", - "type": "string" - }, - "poll_after_seconds": { - "anyOf": [ - { - "maximum": 9007199254740991, - "minimum": -9007199254740991, - "type": "integer" - }, - { - "type": "null" - } - ], - "description": "While confirming: how long to wait before get_quote again." - }, - "status": { - "description": "rating: carriers still answering. questions_pending: ask carrier_questions for the one estimate shown. confirming: Sigo is confirming the price, read again. confirmed: the price is in confirmed_price and the customer pays in the link. declined / not_available: that option is not the answer; other_carrier_questions follows.", - "enum": [ - "rating", - "questions_pending", - "confirming", - "confirmed", - "declined", - "not_available" - ], - "type": "string" - } - }, - "required": [ - "status", - "chosen_quote_id", - "confirmed_price", - "more_options_offered", - "poll_after_seconds", - "next_call", - "note" - ], - "type": "object" - }, - { - "type": "null" - } - ] -} - changed
Output schema / requiredPrevious value: -[ - "quote_id", - "status", - "more_carriers_pending", - "poll_after_seconds", - "pending_note", - "to_final_quote", - "cover_first", - "application", - "state", - "quoted_at", - "expires_at", - "quotes", - "problems", - "contact", - "covers", - "asked_for", - "revised_from_quote", - "price_levers", - "personal_use_note", - "carriers", - "issued_by" -]New value: +[ + "quote_id", + "status", + "more_carriers_pending", + "poll_after_seconds", + "pending_note", + "to_final_quote", + "application", + "state", + "quoted_at", + "expires_at", + "quotes", + "problems", + "contact", + "covers", + "asked_for", + "revised_from_quote", + "price_levers", + "personal_use_note", + "carriers", + "issued_by" +]
- Removed
other_carrier_questions - Changed
start_quote2 fields changed- removed
Output schema / properties / cover_firstRemoved value: -{ - "anyOf": [ - { - "additionalProperties": false, - "properties": { - "chosen_quote_id": { - "description": "The one estimate's quote_id, to pass to carrier_questions. Null when there is none.", - "type": [ - "string", - "null" - ] - }, - "confirmed_price": { - "anyOf": [ - { - "additionalProperties": false, - "properties": { - "currency": { - "const": "USD", - "type": "string" - }, - "due_today": { - "type": "number" - }, - "monthly_payment": { - "type": "number" - }, - "total_for_term": { - "type": "number" - } - }, - "required": [ - "currency", - "due_today", - "monthly_payment", - "total_for_term" - ], - "type": "object" - }, - { - "type": "null" - } - ], - "description": "The carrier's confirmed amounts, once confirmed. Still subject to eligibility and state rules." - }, - "more_options_offered": { - "description": "True when Sigo offers to look at the other carriers beside a confirmed price. Offer it once; other_carrier_questions is how, and only if the customer wants to compare.", - "type": "boolean" - }, - "next_call": { - "description": "Exactly what to call next, with its arguments; null when nothing is.", - "type": [ - "string", - "null" - ] - }, - "note": { - "description": "What to tell the customer and do next, in their language.", - "type": "string" - }, - "poll_after_seconds": { - "anyOf": [ - { - "maximum": 9007199254740991, - "minimum": -9007199254740991, - "type": "integer" - }, - { - "type": "null" - } - ], - "description": "While confirming: how long to wait before get_quote again." - }, - "status": { - "description": "rating: carriers still answering. questions_pending: ask carrier_questions for the one estimate shown. confirming: Sigo is confirming the price, read again. confirmed: the price is in confirmed_price and the customer pays in the link. declined / not_available: that option is not the answer; other_carrier_questions follows.", - "enum": [ - "rating", - "questions_pending", - "confirming", - "confirmed", - "declined", - "not_available" - ], - "type": "string" - } - }, - "required": [ - "status", - "chosen_quote_id", - "confirmed_price", - "more_options_offered", - "poll_after_seconds", - "next_call", - "note" - ], - "type": "object" - }, - { - "type": "null" - } - ] -} - changed
Output schema / requiredPrevious value: -[ - "quote_id", - "status", - "more_carriers_pending", - "poll_after_seconds", - "pending_note", - "to_final_quote", - "cover_first", - "application", - "state", - "quoted_at", - "expires_at", - "quotes", - "problems", - "contact", - "covers", - "asked_for", - "revised_from_quote", - "price_levers", - "personal_use_note", - "carriers", - "issued_by" -]New value: +[ + "quote_id", + "status", + "more_carriers_pending", + "poll_after_seconds", + "pending_note", + "to_final_quote", + "application", + "state", + "quoted_at", + "expires_at", + "quotes", + "problems", + "contact", + "covers", + "asked_for", + "revised_from_quote", + "price_levers", + "personal_use_note", + "carriers", + "issued_by" +]
5 tool updates
- Changed
answer_carrier_questions2 fields changed- added
Output schema / properties / next_callAdded value: +{ + "description": "Exactly what to call next, with its arguments, when something follows here; null otherwise.", + "type": [ + "string", + "null" + ] +} - changed
Output schema / requiredPrevious value: -[ - "answered", - "filed", - "still_needed", - "answers_so_far", - "note", - "next_step" -]New value: +[ + "answered", + "filed", + "still_needed", + "answers_so_far", + "note", + "next_call", + "next_step" +]
- Added
answer_other_carrier_questions - Changed
get_quote2 fields changed- added
Output schema / properties / cover_firstAdded value: +{ + "anyOf": [ + { + "additionalProperties": false, + "properties": { + "chosen_quote_id": { + "description": "The one estimate's quote_id, to pass to carrier_questions. Null when there is none.", + "type": [ + "string", + "null" + ] + }, + "confirmed_price": { + "anyOf": [ + { + "additionalProperties": false, + "properties": { + "currency": { + "const": "USD", + "type": "string" + }, + "due_today": { + "type": "number" + }, + "monthly_payment": { + "type": "number" + }, + "total_for_term": { + "type": "number" + } + }, + "required": [ + "currency", + "due_today", + "monthly_payment", + "total_for_term" + ], + "type": "object" + }, + { + "type": "null" + } + ], + "description": "The carrier's confirmed amounts, once confirmed. Still subject to eligibility and state rules." + }, + "more_options_offered": { + "description": "True when Sigo offers to look at the other carriers beside a confirmed price. Offer it once; other_carrier_questions is how, and only if the customer wants to compare.", + "type": "boolean" + }, + "next_call": { + "description": "Exactly what to call next, with its arguments; null when nothing is.", + "type": [ + "string", + "null" + ] + }, + "note": { + "description": "What to tell the customer and do next, in their language.", + "type": "string" + }, + "poll_after_seconds": { + "anyOf": [ + { + "maximum": 9007199254740991, + "minimum": -9007199254740991, + "type": "integer" + }, + { + "type": "null" + } + ], + "description": "While confirming: how long to wait before get_quote again." + }, + "status": { + "description": "rating: carriers still answering. questions_pending: ask carrier_questions for the one estimate shown. confirming: Sigo is confirming the price, read again. confirmed: the price is in confirmed_price and the customer pays in the link. declined / not_available: that option is not the answer; other_carrier_questions follows.", + "enum": [ + "rating", + "questions_pending", + "confirming", + "confirmed", + "declined", + "not_available" + ], + "type": "string" + } + }, + "required": [ + "status", + "chosen_quote_id", + "confirmed_price", + "more_options_offered", + "poll_after_seconds", + "next_call", + "note" + ], + "type": "object" + }, + { + "type": "null" + } + ] +} - changed
Output schema / requiredPrevious value: -[ - "quote_id", - "status", - "more_carriers_pending", - "poll_after_seconds", - "pending_note", - "to_final_quote", - "application", - "state", - "quoted_at", - "expires_at", - "quotes", - "problems", - "contact", - "covers", - "asked_for", - "revised_from_quote", - "price_levers", - "personal_use_note", - "carriers", - "issued_by" -]New value: +[ + "quote_id", + "status", + "more_carriers_pending", + "poll_after_seconds", + "pending_note", + "to_final_quote", + "cover_first", + "application", + "state", + "quoted_at", + "expires_at", + "quotes", + "problems", + "contact", + "covers", + "asked_for", + "revised_from_quote", + "price_levers", + "personal_use_note", + "carriers", + "issued_by" +]
- Added
other_carrier_questions - Changed
start_quote2 fields changed- added
Output schema / properties / cover_firstAdded value: +{ + "anyOf": [ + { + "additionalProperties": false, + "properties": { + "chosen_quote_id": { + "description": "The one estimate's quote_id, to pass to carrier_questions. Null when there is none.", + "type": [ + "string", + "null" + ] + }, + "confirmed_price": { + "anyOf": [ + { + "additionalProperties": false, + "properties": { + "currency": { + "const": "USD", + "type": "string" + }, + "due_today": { + "type": "number" + }, + "monthly_payment": { + "type": "number" + }, + "total_for_term": { + "type": "number" + } + }, + "required": [ + "currency", + "due_today", + "monthly_payment", + "total_for_term" + ], + "type": "object" + }, + { + "type": "null" + } + ], + "description": "The carrier's confirmed amounts, once confirmed. Still subject to eligibility and state rules." + }, + "more_options_offered": { + "description": "True when Sigo offers to look at the other carriers beside a confirmed price. Offer it once; other_carrier_questions is how, and only if the customer wants to compare.", + "type": "boolean" + }, + "next_call": { + "description": "Exactly what to call next, with its arguments; null when nothing is.", + "type": [ + "string", + "null" + ] + }, + "note": { + "description": "What to tell the customer and do next, in their language.", + "type": "string" + }, + "poll_after_seconds": { + "anyOf": [ + { + "maximum": 9007199254740991, + "minimum": -9007199254740991, + "type": "integer" + }, + { + "type": "null" + } + ], + "description": "While confirming: how long to wait before get_quote again." + }, + "status": { + "description": "rating: carriers still answering. questions_pending: ask carrier_questions for the one estimate shown. confirming: Sigo is confirming the price, read again. confirmed: the price is in confirmed_price and the customer pays in the link. declined / not_available: that option is not the answer; other_carrier_questions follows.", + "enum": [ + "rating", + "questions_pending", + "confirming", + "confirmed", + "declined", + "not_available" + ], + "type": "string" + } + }, + "required": [ + "status", + "chosen_quote_id", + "confirmed_price", + "more_options_offered", + "poll_after_seconds", + "next_call", + "note" + ], + "type": "object" + }, + { + "type": "null" + } + ] +} - changed
Output schema / requiredPrevious value: -[ - "quote_id", - "status", - "more_carriers_pending", - "poll_after_seconds", - "pending_note", - "to_final_quote", - "application", - "state", - "quoted_at", - "expires_at", - "quotes", - "problems", - "contact", - "covers", - "asked_for", - "revised_from_quote", - "price_levers", - "personal_use_note", - "carriers", - "issued_by" -]New value: +[ + "quote_id", + "status", + "more_carriers_pending", + "poll_after_seconds", + "pending_note", + "to_final_quote", + "cover_first", + "application", + "state", + "quoted_at", + "expires_at", + "quotes", + "problems", + "contact", + "covers", + "asked_for", + "revised_from_quote", + "price_levers", + "personal_use_note", + "carriers", + "issued_by" +]
8 tool updates
- First observed
answer_carrier_questions - First observed
carrier_questions - First observed
find_occupation - First observed
get_quote - First observed
list_available_states - First observed
next_question - First observed
resolve_application_link - First observed
start_quote
Related MCP Connectors
Indicative US auto insurance prices for agents: rating facts only, no PII, consented path to agents.
Indicative US auto insurance prices for agents: rating facts only, no PII, consented path to agents.
Indicative US auto insurance prices for agents: rating facts only, no PII, consented path to agents.
Indicative US auto insurance prices for agents: rating facts only, no PII, consented path to agents.
Related MCP Servers
- AlicenseNot gradedqualityDmaintenanceEnables AI agents to get real home & auto insurance quotes and start binding through a network of licensed independent agencies.2Apache 2.0
- FlicenseNot gradedqualityDmaintenanceProvides educational fixed-rate loan estimates with mortgage and auto loan calculators.-
- FlicenseNot gradedqualityBmaintenanceSearch 6,900+ U.S. surety bond requirements across all 50 states. Instant pricing.-
- FlicenseNot gradedqualityNot gradedmaintenanceProvides tools for motor insurance quoting, including vehicle lookups, postcode risk assessments, and premium calculations. It enables users to generate and compare car insurance quotes through natural language interactions.-
Glama MCP Gateway
Add one secure layer between your agents and this server.