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.

Input Schema

TableJSON 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

TableJSON 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.

First observedSep 28, 2026

TDQS

A4.5/5.0

Behavior5/5

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

Annotations only declare readOnlyHint and openWorldHint=false; the description goes well beyond by disclosing that the connector is stateful and retains conversation history, that answers are never lost or repeated, that ZIP is validated here against licensed states, that summary must be read back for correction, and that the two stages yield only estimates with the real quote coming later via the carrier's link. These are non-obvious behavioral traits 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.

Conciseness3/5

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

The call loop is stated twice — once in the opening 'Step 1 of 3' line and again in the second paragraph ('Call it before each question and again after every answer, until ready_to_quote is true, then call start_quote'). The rationale about Sigo's customers quoting on a phone is useful for pacing but verbose. Front-loaded and readable, yet the duplication costs 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?

For a stateful, two-stage conversation driver with a nested answered object, the description covers the full workflow (loop, termination, handoff), the stage semantics, ZIP validation, and the read-back requirement. An output schema exists so return values need not be re-explained, and nothing an agent needs to drive the flow correctly 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 description coverage is 100% and the schema already documents stage, locale, answered and collected in detail, including the enum values and per-field notes. The description reinforces the semantics of `answered` (only this turn's utterance) and `collected` (carried from the previous call), but adds little beyond what the schema text already says, so the baseline 3 is appropriate.

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 ('Returns the one question to put to the customer now'), scopes it to the customer's language and fixed option sets, and explicitly names the sibling it hands off to (start_quote) and the gate (ready_to_quote). An agent can distinguish it from start_quote and get_quote 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?

It gives explicit call timing ('call it before each question and again after every answer'), the loop termination condition ('until ready_to_quote is true'), and the next step ('then call start_quote'), plus a routing hint to get_quote. When-to-use and when-to-stop are both stated, not inferred.

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?