Sigo Seguros car insurance quotes

The next thing to ask the customer

next_question

Read-only

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.

Input Schema

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.

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedOct 14, 2026

addedInput schema / properties / answered / properties / annual_mileage

Added 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"
+}

addedInput schema / properties / answered / properties / annual_mileage_settled

Added value: +{
+  "const": true,
+  "description": "Second round, where asked. Send once every vehicle has its miles per year.",
+  "type": "boolean"
+}

Changed2 schema fields changedSep 30, 2026

addedInput schema / properties / answered / properties / document_number_settled

Added value: +{
+  "const": true,
+  "description": "Second round. Send once every driver who is not excluded has given their document's number.",
+  "type": "boolean"
+}

changedInput schema / properties / answered / properties / document_type / description

Previous 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."

Changed2 schema fields changedSep 30, 2026

removedInput schema / properties / answered / properties / document_number_settled

Removed value: -{
-  "const": true,
-  "description": "Second round. Send once every driver who is not excluded has given their document's number.",
-  "type": "boolean"
-}

changedInput schema / properties / answered / properties / document_type / description

Previous 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."

First observedSep 28, 2026

TDQS

A4.1/5.0

Behavior3/5

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.

Conciseness3/5

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.

Completeness5/5

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.

Parameters3/5

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.

Purpose5/5

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.

Usage Guidelines5/5

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.

All Sigo Seguros car insurance quotes tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?