Skip to main content
Glama

Sigo Seguros car insurance quotes

Start a car insurance quote

start_quote

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.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
emailYesIdentifies 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.
localeYesThe 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.
addressNoSecond 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.
driversYes
vehiclesYes
zip_codeYesThe 5-digit ZIP code where the vehicle is kept. It determines the state.
collectedYesThe `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_ofNoWhen 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_studentNo
is_homeownerNo
correction_ofNoOnly 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_motoristYesWhether 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_insuranceYesWhether the customer currently has car insurance.
prior_coverage_monthsNoSecond 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_expirationNoSecond 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

TableJSON Schema
NameRequiredDescriptionDefault
stateYes
coversYes
quotesYes
statusYes
contactYes
carriersYes
problemsYes
quote_idYesPass this back to get_quote to read the result again.
asked_forYesLabel 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_byYes
quoted_atYes
expires_atYes
applicationYes
pending_noteYesWhat to do while carriers are still answering, in the customer's language. Null once the list is final.
price_leversYes
to_final_quoteYes
personal_use_noteYesPresent 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_secondsYesHow long to wait before calling get_quote again.
revised_from_quoteYesTrue 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_pendingYesTrue when more carriers may still return a price; the list is not final.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.7/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare non-readOnly, open-world, non-idempotent, non-destructive, so the bar is lower, yet the description still adds substantial context beyond them: in-flight retry deduplication, the non-binding nature of the estimate ('does not select a policy, take payment or bind coverage'), the one-quote-at-a-time-per-customer constraint, refusal envelopes carrying code/message/next_step, and the rideshare case that halts quoting entirely. It never asserts a read-only or idempotent effect that the annotations contradict.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Eleven dense paragraphs is defensible for a 15-parameter, multi-step tool, but the opening line ('Step 2 of 3: call it once, with the collected next_question returned when ready_to_quote was true') is opaque before the purpose is stated, and the quote_in_progress behaviour is explained across two separate paragraphs. Every paragraph carries content, but ordering and some repetition cost it.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

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, yet the description still covers the workflow end to end: gathering sequence, second-round batching, revise semantics, concurrent-ask ordering via asked_for, and the refusal envelope. For a tool of this complexity nothing an agent needs to invoke it correctly is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 73%, with a very rich schema that already documents most fields, so the baseline sits near 3. The description earns above baseline by adding cross-parameter workflow semantics the schema cannot express: it enumerates the second-round field set to send with revise_of, explains revise_of/correction_of as identity-preserving re-quotes, and ties address to the ZIP the quote is running on.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource ('Asks Sigo's carriers for car insurance estimates') and immediately scopes the return contract ('returns a quote_id straight away rather than waiting; read the prices with get_quote'). It differentiates from siblings by name — get_quote reads prices, next_question gathers details, and the quote_in_progress path routes back to get_quote — so an agent can pick this tool over its neighbours 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.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicit when-to-call ('once the details are gathered', gathered a step at a time rather than as a form), when-not-to-retry ('If it answers quote_in_progress, do not call it again'), and how to handle the revise path via revise_of versus starting fresh. Concrete alternatives and recovery routes (poll_after_seconds, then get_quote) are named, so nothing 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.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources