Sigo Seguros car insurance quotes

File the customer's answers to the carrier's questions

answer_carrier_questions

Idempotent

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.

Input Schema

Name	Required	Description
`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.

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedOct 14, 2026

changedInput schema / properties / chosen_quote_id / description

Previous value: -"The estimate the customer picked."New value: +"The estimate the customer picked. Left out on the four-carrier path, as at carrier_questions."

changedInput schema / required

Previous value: -[
-  "quote_id",
-  "chosen_quote_id",
-  "answers",
-  "locale"
-]New value: +[
+  "quote_id",
+  "answers",
+  "locale"
+]

removedOutput schema / properties / quote_id

Removed 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"
-  ]
-}

Changed1 schema field changedSep 30, 2026

addedOutput schema / properties / quote_id

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

Changed2 schema fields changedSep 30, 2026

addedOutput schema / properties / next_call

Added value: +{
+  "description": "Exactly what to call next, with its arguments, when something follows here; null otherwise.",
+  "type": [
+    "string",
+    "null"
+  ]
+}

changedOutput schema / required

Previous 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"
+]

Changed2 schema fields changedSep 30, 2026

removedOutput schema / properties / next_call

Removed value: -{
-  "description": "Exactly what to call next, with its arguments, when something follows here; null otherwise.",
-  "type": [
-    "string",
-    "null"
-  ]
-}

changedOutput schema / required

Previous 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"
+]

Changed2 schema fields changedSep 30, 2026

addedOutput schema / properties / next_call

Added value: +{
+  "description": "Exactly what to call next, with its arguments, when something follows here; null otherwise.",
+  "type": [
+    "string",
+    "null"
+  ]
+}

changedOutput schema / required

Previous 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"
+]

First observedSep 28, 2026

TDQS

A4.1/5.0

Behavior5/5

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.

Conciseness4/5

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.

Completeness4/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, 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.

Parameters3/5

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.

Purpose4/5

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.

Usage Guidelines4/5

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.

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?