Skip to main content
Glama
Sign In

Sigo Seguros car insurance quotes

by com.sigoseguros
OverviewDiscussionsAdmin

The carriers' own questions before a firm price

carrier_questions
Read-only

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.

Input Schema

NameRequiredDescriptionDefault
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.
quote_idYesThe handle start_quote returned.
chosen_quote_idNoThe `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

NameRequiredDescriptionDefault
noteYesHow to put these, in the customer's language.
preambleYesSigo'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_stepYesWhere the customer finishes. Theirs at any point, not only at the end.
questionsYesIn the order the platform ranked them.
ask_togetherYesCodes 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_neededYesWhat 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_hereYesFalse 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.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changed
    • changedInput schema / properties / chosen_quote_id / description
      Previous 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."
    • changedInput schema / required
      Previous value: -[
-  "quote_id",
-  "chosen_quote_id",
-  "locale"
-]New value: +[
+  "quote_id",
+  "locale"
+]
    • changedOutput schema / properties / can_answer_here / description
      Previous 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."
  2. First observed

TDQS

A3.9/5.0
Behavior4/5

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.

Conciseness3/5

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.

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

Parameters3/5

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.

Purpose4/5

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.

Usage Guidelines4/5

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.

All Sigo Seguros car insurance quotes toolsInspect
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