Sigo Seguros car insurance quotes

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

Annotations already declare a non-read-only, idempotent, non-destructive, open-world write, and the description is consistent with all of them. It adds genuine behavioral context beyond the annotations: answers are buffered until the full set is given, the token survives a re-quote (supporting idempotency), and payment/signing/binding are out of scope. It stops short of describing error behavior or the returned link's use in depth.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

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

The instruction is front-loaded, which is good, but the four-paragraph narrative repeats the answers_so_far mechanic twice ('passing answers_so_far back each time' and 'Pass the answers_so_far from the previous call back in') and re-states the schema's own descriptions. Some sentences could be cut without losing meaning.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a stateful, multi-step, 5-parameter write tool with an output schema, the description covers sequencing, the carry-back token, re-quote continuity, and scope limits. With an output schema present, return values need no explanation, so nothing an agent needs is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3, but the description adds meaning the schema does not: answers must be given 'under the code it came back with' and 'only what the customer actually said', and only the new answer goes into `answers` while prior ones travel in `answers_so_far`. That incremental-input semantics is the key to calling this correctly.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

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', 'saves what the customer answered against their application') and names the preceding action ('After carrier_questions'), cleanly separating it from the sibling that surfaces questions. An agent can tell what this does and where it sits in the flow without opening the schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives explicit ordering ('After carrier_questions'), the iterative protocol ('passing answers_so_far back each time, until the set is complete'), and a clear exclusion ('This does not take payment, sign anything or bind coverage'). Both when-to-use and when-not are covered, plus the re-quote case.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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

Beyond the readOnlyHint/openWorldHint annotations, it discloses rich behavior: say preamble first, one ask_together block per turn, questions must be relayed verbatim and not reworded, and can_answer_here=false hands off to a Sigo agent while the customer retains the link. This is well past what the annotations cover.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

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

Dense but mostly earned; the turn protocol and verbatim requirement each justify their place. The first sentence is front-loaded with opaque references rather than the tool's core purpose, which costs a point.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

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 not be explained. The description covers the gating step, the per-turn asking protocol, the handoff when can_answer_here is false, and the customer-link persistence — everything needed to invoke and use it correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents quote_id, chosen_quote_id and the locale language semantics. The description adds no further parameter-specific detail beyond the schema, so the baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource: it returns the questions the carrier asks in the customer's state (attestations and disclosures). It is distinguishable from answer_carrier_questions and next_question. The opening sentence, however, leans on unexplained context ('the three steps', 'to_final_quote.next_call') that an agent must already know, which blunts the clarity slightly.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly states the trigger condition (after the customer has picked an estimate, when to_final_quote.next_call names it) and routes to the alternative (send answers with answer_carrier_questions). The preamble/ask_together turn protocol is spelled out, leaving no inference needed.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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

Annotations already declare readOnlyHint and openWorldHint, so the safety profile is covered. The description adds genuinely useful behavior beyond them: the catalogue is in trade names, matching is approximate so an empty list is meaningful, and the result must be verified rather than guessed. It does not discuss rate limits or return shape, but the output schema covers the latter.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

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

Front-loaded with the tool's role before the how-to, and every clause is actionable. Minor redundancy between 'turns the customer's words into the occupation code' and 'Turns what the customer said they do into the carrier's own occupation codes' costs it the top mark.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Output schema exists so return values need no explanation, and annotations carry the safety profile. The description covers purpose, workflow position, and empty-result handling, leaving only minor gaps such as whether multiple matches can be returned. Adequate for a two-parameter lookup.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so `said` and `locale` are already fully documented, including the enum and locale's effect on notice language. The description reinforces the 'customer's own words' intent but adds no syntax or constraints beyond the schema. Baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific transformation (customer's spoken words → carrier occupation code) and names the sibling it feeds (`start_quote` / the `occupation` field). An agent can distinguish it from next_question, carrier_questions, and get_quote without opening schemas.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicit when-to-call ('Call it before sending `occupation` on a driver'), why the lookup is necessary ('the code is never something to guess at'), and what to do on an empty result ('ask them another way rather than settle for the nearest thing'). It also locates itself in the flow ('outside the three steps').

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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.

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.

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.

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.

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.

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.

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description goes well beyond that by disclosing the agency/commission/broker-fee model and, importantly, the policy for answering fee questions ('saying Sigo charges nothing is false wherever it does charge'), which is real behavioral context an agent needs.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

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

The description is long and mixes distinct concerns — flow sequencing, licensing geography, organizational identity, and fee/commission policy — with the core purpose appearing late. Much of the fee-model prose is tangential to invoking this tool, so several sentences do not earn their place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

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 no explanation, and the description covers the who/what/when for this lookup. It is arguably over-complete on domain policy rather than under-complete, so nothing an agent needs to call it correctly is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% and the single enum parameter 'locale' is fully documented in the schema with its own rationale. The description adds no locale syntax or formatting detail beyond the schema; the 'state_is_decided_by' reference is about domain logic, not the parameter. Baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific resource — 'The US states Sigo Seguros is licensed to sell car insurance in' — and distinguishes itself from the flow siblings (next_question, start_quote, get_quote). However, the purpose statement is buried after flow-ordering guidance rather than front-loaded, which slightly weakens immediate clarity.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives clear context: 'Ask this before collecting details, so a customer elsewhere is not taken through a full quote,' which effectively states when to use it and the consequence of skipping it. There is implicit exclusion guidance (customers outside licensed states), though no explicit named alternative tool.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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.

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.

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.

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.

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.

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.

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

Annotations only declare readOnlyHint and openWorldHint. The description adds real behavioral context beyond them: idempotence ('asking twice changes nothing'), no side effects ('opens nothing on the customer's behalf'), and a disclosure posture ('reports no price, carrier or personal detail... nothing here that identifies its owner'), which tells the agent not to expect personalized or sensitive output.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

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

Core behaviour and the trigger are front-loaded, and every sentence carries information. It is slightly dense and the opening sentence is a fragment that requires reading on to parse, keeping it just short of a 5.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

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 not be described, yet the description still states what the answer contains and the disclosure constraints. With only two fully-documented params and annotations covering safety, nothing an agent needs to call this correctly is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3, but the description adds accepted-format semantics the schema does not: it resolves short links, long links and bare codes, tolerates surrounding words and punctuation, and must be passed verbatim. That is genuine value over the schema text.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Specific verb+resource: it says what a Sigo link points at, how far the application has progressed, and the next required customer action. It also explicitly positions itself against the sibling flow ('Outside the three steps'), so an agent can distinguish it from start_quote/next_question/get_quote without reading schemas.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives a concrete trigger condition ('Call it when someone shows up with a link — from an email, a text, or their own notes — and asks for help finishing') and names the alternative path (the three-step flow) it sits outside of. Routing is unambiguous.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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

Annotations already declare non-readOnly, open-world, non-idempotent, non-destructive, so the bar is lower, yet the description still adds substantial context beyond them: in-flight retry deduplication, the non-binding nature of the estimate ('does not select a policy, take payment or bind coverage'), the one-quote-at-a-time-per-customer constraint, refusal envelopes carrying code/message/next_step, and the rideshare case that halts quoting entirely. It never asserts a read-only or idempotent effect that the annotations contradict.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

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

Eleven dense paragraphs is defensible for a 15-parameter, multi-step tool, but the opening line ('Step 2 of 3: call it once, with the collected next_question returned when ready_to_quote was true') is opaque before the purpose is stated, and the quote_in_progress behaviour is explained across two separate paragraphs. Every paragraph carries content, but ordering and some repetition cost it.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

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, yet the description still covers the workflow end to end: gathering sequence, second-round batching, revise semantics, concurrent-ask ordering via asked_for, and the refusal envelope. For a tool of this complexity nothing an agent needs to invoke it correctly is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 73%, with a very rich schema that already documents most fields, so the baseline sits near 3. The description earns above baseline by adding cross-parameter workflow semantics the schema cannot express: it enumerates the second-round field set to send with revise_of, explains revise_of/correction_of as identity-preserving re-quotes, and ties address to the ZIP the quote is running on.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource ('Asks Sigo's carriers for car insurance estimates') and immediately scopes the return contract ('returns a quote_id straight away rather than waiting; read the prices with get_quote'). It differentiates from siblings by name — get_quote reads prices, next_question gathers details, and the quote_in_progress path routes back to get_quote — so an agent can pick this tool over its neighbours 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.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicit when-to-call ('once the details are gathered', gathered a step at a time rather than as a form), when-not-to-retry ('If it answers quote_in_progress, do not call it again'), and how to handle the revise path via revise_of versus starting fresh. Concrete alternatives and recovery routes (poll_after_seconds, then get_quote) are named, so 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.