Skip to main content
Glama

Sigo Seguros car insurance quotes

Read car insurance estimates

get_quote
Read-only

Step 3 of 3: read the quote_id start_quote returned, after poll_after_seconds, until more_carriers_pending is false. Never start_quote again to refresh a result.

Reads the estimates for a quote_id returned by start_quote. Carriers answer at different speeds: when more_carriers_pending is true the list is not final and poll_after_seconds says how long to wait before asking again. The list closes within a minute either way, with whatever arrived — a carrier that did not answer is not a price, and there is none to go looking for. Once it is closed, to_final_quote.next_call is what to do next. No price here is final, in any round: the final quote is calculated by Sigo in the link, after the carrier's questions.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
localeNoThe 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.es
quote_idYesThe handle start_quote returned.

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.6/5.0
Behavior5/5

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

Annotations already cover read-only and open-world, but the description adds substantial behavior beyond them: carriers answer asynchronously, the list may be incomplete while more_carriers_pending is true, the list closes within a minute with partial results, missing carriers are not prices, and no price is final at this stage. This is exactly the kind of operational context annotations cannot express.

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-loaded with the step position, the wait condition, and the prohibition, which is the right ordering. It runs long and a few sentences are slightly redundant/quasi-poetic ('there is none to go looking for', 'no price here is final, in any round'), costing a point without hurting comprehension.

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 needn't be documented; the description instead supplies the asynchronous polling semantics, termination condition, and hand-off to the next step. Nothing an agent needs to invoke and loop this tool 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 coverage is 100% and the locale parameter's schema description is already very rich (language of the notice, Sigo serves only es/en). The description restates quote_id's origin without adding syntax or format beyond the schema, 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?

States a specific verb and resource (read the estimates for a quote_id returned by start_quote) and explicitly distinguishes itself from the sibling start_quote, which it warns against re-invoking. An agent can place it in the flow 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?

Gives explicit when-to-use ('Step 3 of 3'), the polling loop condition (wait poll_after_seconds, repeat until more_carriers_pending is false), an explicit prohibition ('never start_quote again to refresh'), and what to do after closure (to_final_quote.next_call). 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