Coverage Cat

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

Annotations already declare readOnly, idempotent, non-destructive, closed-world behavior. The description adds meaningful context beyond them: the returned fields (carrier id, name, five-point premium spread in USD, normalized inputs) and the critical caveat that results are model estimates, not bindable quotes. Rate limits, auth needs, and latency are not covered but are less relevant for a safe read-only estimator.

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?

Three compact sentences: purpose first, return shape second, research-only caveat third. Every sentence carries distinct information and nothing is repeated from the schema or annotations.

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 11 parameters, an output schema, and fully covering annotations, the description supplies the remaining decision-relevant facts: what the estimate covers, what comes back, and that it is not a bindable quote. Nothing needed 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 description coverage is 100%, so every parameter (including seed, deductibles, and vehicle fields) is already documented by the schema. The description adds no parameter-level detail beyond the schema, which is the correct baseline-3 case when the schema does the heavy lifting.

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 ('Estimate monthly auto premiums for one driver and vehicle profile across several carriers'), including scope (single profile, multiple carriers). This clearly separates it from sibling calculators like home_calculator and umbrella_calculator without needing to inspect 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?

Frames the tool as research-grade modeling ('model estimates for research, not bindable quotes'), which implicitly routes binding actions to siblings like homeowners_consumer_bind. However, it never explicitly names an alternative tool or states when-not-to-use conditions, so usage is clear but not fully enumerated.

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 readOnly, idempotent, non-destructive, closed-world behavior. The description adds real value beyond that by enumerating the returned scenarios (no coverage, collision only, both, after-claim variants) and warning that these are model estimates, not bindable quotes.

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?

Three sentences, front-loaded with purpose then outputs then the estimate caveat. Dense but nearly every clause earns its place; the long enumeration of return scenarios is the only slightly heavy part.

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?

Given an output schema exists, return values need not be explained, yet the description usefully summarizes them and flags the non-bindable nature of the estimates. Coverage is solid for a read-only calculator; only sibling differentiation is thin.

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 all 11 inputs, establishing a baseline of 3. The description references projection_years, a field not present in the input schema, but adds no syntax or default detail for the documented parameters.

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 (estimate collision/comprehensive cost) and scopes it to one driver and vehicle profile, which is precise. It does not differentiate itself from the sibling auto_estimates tool, leaving some ambiguity about which estimator to pick.

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?

Frames the decision context clearly ('to help decide whether to carry them'), which tells the agent when this tool is appropriate. It offers no explicit exclusions or named alternatives, so it stops short of full routing guidance.

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?

Adds substantial behavior beyond the annotations: it discloses that the call records request attribution and rotates follow-up access, that in the umbrella sandbox polling advances checkout and can create a synthetic policy without issuing real coverage, and that email alone cannot resume a prior draft. This directly explains why readOnlyHint=false and idempotentHint=false despite the read-like framing — exactly the kind of context annotations cannot convey.

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 lead sentence is well front-loaded, but the body is a dense run-on mixing return-field enumeration, auth handoff rules, agent behavior scripts ('say explicitly that the application is not submitted yet'), and birthday normalization. Several clauses (birthday format normalization, a long list of returned state keys) do not belong in a status-read description and dilute the actionable parts.

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, yet the description still spends a long clause enumerating return fields (detail_status, next_question, selection_token, etc.), which is redundant. Auth, sandbox, and draft-resumption edge cases are otherwise well covered for a stateful handoff tool, so an agent has enough to call 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 coverage is 100% and both parameters are fully documented in the schema, so baseline is 3. The description adds real meaning on top: it explains that the token rotates per response and must be the LATEST one from the previous successful response, and that uid must be carried across every call on the same application — operational semantics the schema states only tersely.

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?

Opens with a specific verb+resource: 'Read the status of an umbrella application or an existing homeowners policy,' and the follow-up framing ('reuse uid and the latest intake_access_token... on each follow-up') makes clear this is the status-poll endpoint rather than a patch/verify step. It does not name a sibling tool explicitly, so an agent must infer that consumer_intake_patch and consumer_intake_verify_email are the alternatives.

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 concrete operating conditions: reuse uid plus the latest token on every follow-up, stay on this same follow-up tool, stay on the default consumer-operated subset, and hold missing umbrella fields until the pre-submit review turn. The gaps are that it never states when NOT to call it (e.g. when to call consumer_intake_patch or umbrella_consumer_prefill instead) and the guidance is interleaved with return-field detail rather than organized.

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 destructiveHint=true, idempotentHint=true, and openWorldHint=false, but the description adds real operational context: the stateless MCP 2026-07-28 token requirement, legacy hidden-session auth, and that it returns the same follow-up payload as `consumer_intake_issues`. It stops short of explaining what submission actually commits or whether a confirmed submission is reversible, which matters for a destructive mutation.

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 purpose, then progressively narrower operational rules, and nearly every clause carries a prohibition or precondition. It is long and reads as a dense imperative run-on covering several modes at once, with some redundancy against the schema (token privacy is stated twice), costing it the top score.

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 10-parameter, nested, destructive, multi-mode tool it covers the hard parts: auth/statefulness, retry safety, staged review sequencing, what not to send pre-submit, and shopper-facing honesty about submission status. An output schema exists and the description routes the agent to the analogous sibling payload, so return values need no further explanation.

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 already 100%, so the schema carries the parameter burden and the baseline is 3. The description does add scoping meaning the schema lacks in one place — the staged-review rule that only explicitly missing shopper-owned details and corrections belong in the patch, plus the birthday format conversion — but most of its parameter talk (token, `confirm_submission`) restates 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?

The opening sentence names three distinct operations with specific verbs and resources: patching/submitting a consumer-prefill umbrella handoff, and replying to existing-policy support correspondence. It is clearly separable from siblings like `umbrella_consumer_prefill` (origination) and `consumer_intake_issues` (issue surfacing), and it states this is the follow-up tool to stay on.

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 routing and sequencing rules: reuse uid plus the latest `intake_access_token` from the previous successful response, stay on this same follow-up tool, stay on the default consumer-operated subset, set `confirm_submission` only on the final review confirmation, and do not ask for umbrella credit consent here. It also names exclusions (no vehicles rows on this pre-submit patch) and a normalization rule (MM-DD-YYYY to YYYY-MM-DD).

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 mutation, irreversibility, and idempotency, so the description focuses on what annotations can't convey: the link only goes to the email on file and the shopper must never paste the link or code into chat. That is genuine security and eligibility context. It stops short of describing what the tool returns or failure modes (e.g. expired intake), which would push this to a 5.

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?

Four compact sentences in execution order: trigger, ask, call, poll, plus a guardrail. Front-loaded and free of restated metadata such as parameter types or return shape.

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, and annotations cover the safety profile. The description supplies the remaining pieces an agent needs — trigger condition, consent step, follow-up polling, and privacy rule — which is everything required to call this correctly within a multi-step intake flow.

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 property descriptions already explain uid reuse, the confirm_send consent meaning, and idempotency-key retry semantics. The description reinforces the consent ordering behind confirm_send but adds no new syntax, format, or validation detail beyond the schema. Baseline 3 applies when the schema does the heavy lifting.

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 — send a verification email to the shopper's email on file — and pins the trigger condition (`consumer_intake_issues` reports verification.required). It explicitly names the sibling it coordinates with, so the agent can separate this from consumer_intake_issues and consumer_intake_patch 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?

Gives an explicit precondition (verification.required from consumer_intake_issues), an intermediate step (ask the shopper first), a hard invocation constraint (confirm_send: true), and a follow-up loop (poll consumer_intake_issues until the flag clears). When-to-use, when-not-to-call-yet, and what to do afterward are all covered.

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, idempotentHint, openWorldHint=false and destructiveHint=false, so safety behavior is fully covered. The description adds useful context that href may be null and that content is returned in markdown/JSON/YAML, but does not discuss permissions, limits, or failure behavior beyond that.

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?

A single, front-loaded sentence with no filler; the action is stated first and the returned fields follow. Slightly dense but every clause earns its 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?

For a one-parameter read tool with full annotation coverage and an output schema, the description is nearly sufficient. The remaining minor gap is the absence of guidance on what to do when a URI is unknown or invalid, which the output schema does not cover.

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% for the single parameter and the schema already documents the accepted 'coveragecat://' and 'ui://' URI forms and their origin. The description adds only 'by URI' and does not extend meaning 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?

States a specific verb and resource ('Read one Coverage Cat docs resource by URI') plus the source ('default consumer MCP'), which is clear. The singular 'one ... by URI' implicitly distinguishes it from docs_list_topics and docs_search, but it never names them, so differentiation is left to inference.

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?

The description implies usage (fetch a single resource once you have its URI), and the schema reinforces this by saying the URI comes from docs_list_topics or docs_search. However, there is no explicit when-to-use vs. sibling statement or precondition in the description itself.

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 readOnly, idempotent, non-destructive, and closed-world, so the safety profile is covered. The description adds one useful non-annotation fact — that topics come from the same consumer MCP connection — but says nothing about pagination/ordering beyond the schema and merely restates output 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?

A single sentence, front-loaded with the verb and resource, with zero filler. Everything stated is either the action or its scope.

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 a low-complexity, zero-required-parameter read tool, full annotation coverage, and an output schema that already defines the return shape, the description is close to sufficient. The only missing element is routing guidance among the doc-related siblings.

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%: limit and category are fully documented in the schema, including the enum meanings and behavior when omitted. The description adds no parameter-level information beyond what the schema already provides, so the baseline of 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 gives a specific verb (List) and resource (Coverage Cat documentation topics) plus the fields returned, so the operation is unambiguous. It does not, however, distinguish itself from siblings docs_search and docs_get_resource, which are the obvious alternatives an agent would weigh.

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?

No statement of when to use this index versus docs_search or docs_get_resource, and no prerequisites. The only usage signal is the category enum in the schema, which implies browsing but is not framed as guidance relative to alternatives.

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 readOnly, idempotent, non-destructive, closed-world behavior, so the safety profile is covered. The description adds genuine behavioral detail beyond them: the ranking rule (word overlap in title, summary, URI, category), the fields carried in each match, and the meaning of an empty matches list. No rate limits or pagination are mentioned, but for a read-only search this is solid.

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?

Two sentences, purpose front-loaded, no filler. The middle sentence is dense with ranking and match-field information but each clause earns its 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?

An output schema exists, so return values need not be re-explained, yet the description still summarizes match fields and the empty-result case. Combined with the explicit handoff to docs_get_resource and the read-only annotations, an agent has everything needed to call this 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 coverage is 100%, so both parameters are documented in the schema and the baseline is 3. The description goes beyond that by explaining how the query string is actually consumed (word matching against title, summary, URI, category), which adds semantic value about query construction and result ordering.

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 (Search) and resource (docs), enumerates the doc types covered (quickstart, auth, sandbox, OpenAPI, runtime skill docs) and scopes it to 'this consumer MCP connection'. This is enough to distinguish it from docs_list_topics and docs_get_resource without opening any 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 an explicit follow-up path: 'Pass a match's uri to docs_get_resource to read it', which routes the agent to the correct sibling for retrieval. It stops short of stating when not to use this tool (e.g. versus docs_list_topics for enumeration), so it is clear context without exclusions.

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 readOnly/idempotent/non-destructive, and the description adds a meaningful accuracy caveat ('model estimates, not carrier quotes') that tells the agent how much to trust the output. It stops short of describing determinism (the seed param) or the sampling behavior.

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 decision question, followed by a compact enumeration of returns and the estimate caveat. The return-value listing is somewhat verbose given an output schema exists, but nothing is wasted or confusing.

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 read-only calculation tool with full annotation coverage and a present output schema, the description covers purpose, returns, and an accuracy disclaimer. The main gap is the absence of routing guidance to sibling estimation tools.

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 all 12 parameters are already documented in the schema. The description only alludes to the collision deductible and offers no additional parameter semantics beyond what the schema provides, 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?

States a specific verb and decision ('Estimate whether filing an auto collision claim costs more than paying for the repair yourself'), clearly distinguishing this break-even calculator from the generic auto_estimates sibling, though it does not name that sibling explicitly.

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?

The purpose implies when to use it (a claim-vs-pay decision), but there is no explicit when-to-use guidance or reference to alternatives such as auto_estimates or collision_and_comprehensive_coverage. Usage is inferable but not spelled out.

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, idempotentHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description goes beyond that by disclosing what is returned: normalized inputs, available risk-factor ids, and ZIP-level context notes — helpful behavioral detail about the estimate's provenance.

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?

A single sentence that front-loads the core purpose and then appends the return-value detail; nothing is redundant. It is slightly dense with three output clauses, but each clause carries distinct information.

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 annotations covering the safety profile and an output schema existing, the description does not need to enumerate return fields. It adequately conveys scope, required inputs, and the nature of the result for a read-only three-parameter estimator; only sibling routing is absent.

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 fully documents zip, home_sqft, and risk_factors, making a 3 the baseline. The description's mention of 'normalized inputs' and 'available risk-factor ids' loosely maps to the risk_factors parameter but adds no syntax or format detail beyond the schema.

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 ('Estimate') and resource ('annual and monthly home insurance ranges') with an explicit geographic scope ('California property'), and it names the outputs produced. It does not explicitly differentiate itself from the sibling umbrella_calculator, but the resource noun makes the domain distinction legible.

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?

There is no when-to-use statement, no prerequisite conditions, and no routing to or away from alternatives such as umbrella_calculator or homeowners_consumer_prefill. The California-property scope is the only contextual hint, so usage must be 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?

The description earns credit for explaining the otherwise puzzling readOnlyHint=false: the call "records access attribution and rotates follow-up access, but does not advance or change policy state." It also discloses statelessness under MCP 2026-07-28, token privacy requirements, and legacy host session behavior. It stops short of saying how token rotation affects a stale/expired token or what happens when no policy is on file.

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 first sentence front-loads what the tool returns, and the operational constraints follow in a logical order. Some redundancy exists between "stay on this same MCP follow-up tool" and "without switching to delegated tools," and the legacy-host sentence is marginally tangential, but nearly every sentence carries actionable information.

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-value detail is correctly omitted, and the description covers auth, statelessness, side effects, and placement in the workflow. What remains missing is error/edge behavior — e.g., what happens if no policy is on file yet or if the token is no longer the latest one.

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 both parameters are already documented in the input schema, which sets the baseline at 3. The description does add a usage rule beyond the schema — reuse the latest token from the previous successful response on every follow-up — but it largely restates the schema wording about uid and token privacy rather than adding new format or failure semantics.

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 opening sentence gives a precise verb ("Read") and enumerates the exact resources returned: the bound or cancelled homeowners policy record, policy documents, and cancellation/refund/support request history. It is clearly distinct from umbrella-oriented siblings by naming homeowners policy scope, but it never names the parallel umbrella_consumer_policy or homeowners_consumer_service tools, so the differentiation is implied rather than stated.

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 states explicit triggers — "after Coverage Cat reports a policy on file, or after a service request is opened" — and an explicit boundary: show policy facts "without switching to delegated tools" and "stay on this same MCP follow-up tool." That is a when-to-use plus a when-not-to-use routing instruction, which is the full bar.

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 destructiveHint=true and idempotentHint=true, but the description adds real context beyond them: the token is required for stateless MCP 2026-07-28 hosts, must be kept private and never shown to the shopper, and legacy hosts may carry hidden session authorization. It also explains the two-phase preview/confirm behavior that the destructive hint alone doesn't convey. Minor deduction for restating idempotency/retry ideas that the schema already documents in detail.

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 critical ordering rule (preview, then confirm) and the token requirement are stated early, which is good front-loading. However, several sentences are redundant: "keep tokens private and stay on this same MCP follow-up tool" is echoed by "stay on the same consumer-operated MCP subset after bind," and the token privacy point is repeated from the schema. Tightening would improve 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?

With an output schema present and full schema coverage across 8 parameters, the description focuses appropriately on workflow, consent, and token handling — the things structured fields can't express. It covers the risky path (confirm_request) and the host-compatibility caveat well; only the repeated clauses keep it from being fully tight.

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 carries the meaning of every parameter, including request_type's enum semantics and confirm_request's preview-vs-open distinction. The description only reinforces the reuse of uid and intake_access_token rather than adding new parameter-level detail. 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 opening sentence gives a specific verb pair ("preview or open") and a specific resource set ("cancellation, refund, or support request for a consumer homeowners policy"), which separates it from the umbrella_consumer_service and auto siblings. It stops short of naming a sibling outright, so an agent must infer the line vs. umbrella_consumer_service from the word "homeowners."

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 states an explicit workflow: preview first, then send confirm_request: true only after shopper approval, and never describe the issue as completed until Coverage Cat confirms the outcome. It also says to stay on this same follow-up tool rather than drifting to another, which is exactly the kind of routing guidance an agent needs.

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 readOnly/idempotent/non-destructive/closed-world, so safety is covered. The description adds real behavioral context beyond that: it flags that outputs include a break-even year, that unverified coverage comparability is surfaced rather than assumed, and that 'no carrier prices are invented' — i.e., it computes only from user-supplied quotes and never fabricates market data. That last point is the kind of trust signal 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?

Three sentences: purpose, inputs, outputs plus caveats. Front-loaded with the comparison framing, and no sentence is redundant — the final clause about not inventing carrier prices could easily have been omitted but earns its place as a trust qualifier.

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 spelled out in detail, yet the description still names the headline outputs. With 11 parameters and only 6 required, the description's mention of entering premiums and upgrades tells the agent what to gather; annotations cover the safety profile. Nothing material is missing for correct invocation.

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 per-field semantics (annualize a six-month premium, whole US dollars, upgrade costs) are already fully documented. The description groups the inputs conceptually into net premiums, underlying-limit upgrades, and switching cost, which helps orient the agent but adds no format or edge-case detail 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?

Specific verb-plus-resource: 'Compare the total cost of keeping existing home and auto insurance with standalone umbrella coverage versus moving all three to a bundle.' It names both sides of the comparison and the deliverable (first-year/multi-year totals, savings, break-even year), which distinguishes it from umbrella_calculator and umbrella_limit_planner siblings that compute a single figure rather than a cross-scenario delta.

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?

The scenario is clearly framed — user already has home and auto, is deciding whether to add standalone umbrella or rebundle all three — and it lists what inputs to supply. It gives no explicit exclusions or named alternatives (e.g., when to prefer umbrella_limit_planner for sizing), so the agent must infer routing from the comparison framing rather than being told outright.

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?

The annotations already establish read-only, idempotent, non-destructive, closed-world behavior. The description adds useful context that this is a research-only directional estimate rather than a binding quote or purchase action, though it does not discuss auth, limits, or detailed eligibility behavior.

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 two sentences and front-loads what the tool returns before stating the usage boundary. Every sentence contributes directly to selection or correct use.

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 an 11-parameter estimate with an output schema and rich annotations, the description covers purpose, output nature, and the key usage boundary. It could say more about estimate limitations or eligibility implications, but the schema and output schema carry the detailed parameter and return-value information.

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 all 11 parameters are already documented in the schema. The description only implies that those factors drive risk class and per-factor impacts; it adds no parameter syntax, defaults, or special-case guidance beyond the schema.

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: an estimate of annual personal umbrella pricing bands, inferred risk class, and per-factor impacts. It also distinguishes this research-only pricing tool from the shop/buy umbrella sibling tools.

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 an explicit when-to-use case (price exploration) and a when-not case (when the shopper wants Coverage Cat to shop for or buy umbrella insurance). It does not name the specific alternative consumer/shop tools, so the routing is clear but not fully explicit.

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 destructiveHint=true, idempotentHint=true, and readOnlyHint=false, so the description isn't obligated to restate safety. It does add valuable operational behavior: the stateless MCP 2026-07-28 token requirement, legacy hidden session auth, and the 5-10 minute readiness window after uploads land. It does not explain what makes the call destructive (e.g., whether re-uploading supersedes earlier documents), which is the one gap.

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?

Purpose is front-loaded and every major rule appears, but the paragraph drifts into repeated directives ('Keep tokens private', 'Stay on this same MCP follow-up tool', 'Stay on the same consumer-operated MCP subset') that partly duplicate the schema's intake_access_token description. A few sentences could be merged or dropped without losing information.

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 auth, idempotency intent, batching, fallback transport, and expected downstream timing. Only the destructive/replacement semantics of a re-upload are left unexplained for a mutation tool.

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; the description still adds meaning by instructing reuse of uid and the latest intake_access_token across follow-ups and by steering agents toward attachments rather than hand-building base64 content. It also resolves the schema's either/or mode ambiguity in prose.

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 first sentence names a specific verb and resource ('Upload declarations or auto declarations') and pins the exact flow ('consumer-prefill umbrella post-choose'). This clearly separates it from siblings like umbrella_consumer_prefill and umbrella_consumer_bind.

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 precondition ('only after selection and only when Coverage Cat says documents are needed'), a preferred invocation mode ('prefer one attach call with attachments'), and a concrete alternative route (REST binary /api/intake/{uid}/attach-upload for file-on-disk runtimes). That is when, when-not, and alternatives all in one paragraph.

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 flag destructiveHint=true and idempotentHint=true, so the description focuses on what they cannot convey: stateless MCP 2026-07-28 requires the token on every follow-up, legacy hosts may carry hidden shopper session auth, and tokens must be kept private. It does not explain what the destructive bind actually commits (e.g., whether an offer is bound or a policy created), leaving one meaningful behavioral gap.

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 gating condition is correctly front-loaded, but the prose is dense and repetitive, with overlapping directives ('Keep tokens private', 'Stay on this same MCP follow-up tool', 'Stay on the same consumer-operated MCP subset') and a trailing scope lecture about Markel vehicle details that could be compressed to one clause.

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 multi-step, stateful, destructive bind operation the description covers the state-machine entry condition, credential handling, and payload scoping, and an output schema exists so return values need not be described. What remains missing is the consequence of a successful bind and whether the intake object's expected fields can be discovered before calling.

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 baseline is 3. The description largely restates what the schema already states about uid and intake_access_token; its only real addition is the constraint to send 'only the current bind-stage fields' inside intake, which is a thin increment over the structured data.

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 ('Continue the consumer-prefill umbrella bind follow-up') and pins the exact precondition ('only after select returns needs_more_info_to_bind or ready_to_finalize'). This clearly separates it from umbrella_consumer_prefill and umbrella_consumer_select in the sibling list.

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 an explicit when-to-use gate tied to the prior tool's return states, plus concrete reuse instructions for uid and intake_access_token. It also forbids repurposing: 'stay on this same MCP follow-up tool' and don't move the vehicle-details question into pre-submit review.

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 declare destructiveHint=true, idempotentHint=true and readOnlyHint=false, and the description goes well beyond them: statelessness of MCP 2026-07-28 and the token requirement, the rule not to collect card details in conversational text, the two-phase handshake, and the fallback path. The one gap is that it never explains what the destructiveHint actually destroys or whether a prepared SetupIntent is reversible, so an agent cannot fully assess the mutation's blast radius.

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 purpose and then sequenced as a procedure, which suits a multi-step tool. There is some redundancy ('Keep tokens private' and 'do not show it to the shopper' duplicate the intake_access_token schema description) and 'Stay on the same consumer-operated MCP subset' is vague filler, but most sentences carry actionable constraints.

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 destructive, stateful, multi-phase payment tool this covers preconditions, ordering, privacy constraints, error/retry behavior and the fallback branch; the existence of an output schema means return values need not be described. An agent has everything required to invoke it correctly on the first attempt.

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; the description earns an extra point by adding workflow meaning the schema does not convey, namely that payment_collection_requested is the first-call mode and that setup_intent_id plus payment_method_id must be sent together on the follow-up call. It also reinforces the token-reuse rule across follow-ups.

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 ('Prepare secure Stripe payment collection or submit the resulting payment method') and scopes it to the 'consumer-prefill umbrella post-choose flow,' which cleanly separates it from siblings like umbrella_consumer_bind, umbrella_consumer_select and umbrella_consumer_attach. The two operating modes are named explicitly.

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 hard precondition ('Use this only after Coverage Cat says payment_needed'), an ordered procedure ('First call it with payment_collection_requested: true'), an explicit prohibition ('do not send the shopper straight to payment_url before you try this native step'), and the fallback trigger ('If UI support is unknown or unsupported, or if secure setup fails in chat'). Nothing about when-to-use 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?

The description explains the surprising readOnlyHint=false annotation: the call records access attribution and rotates the follow-up access token, but does not advance or change policy state. It also discloses the stateless MCP 2026-07-28 token requirement and that legacy hosts may rely on hidden shopper session authorization. That is exactly the behavioral context annotations alone cannot convey.

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?

Purpose is front-loaded, which is good, but the token guidance is repeated across multiple sentences and partially duplicates what the schema already states about keeping the token private. The prose is denser than needed for a two-parameter read tool.

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 shape needn't be described, and the description instead covers auth, token chaining, and state effects. What an agent needs to call this correctly is present. Only the relationship to specific sibling policy/service tools is left implicit.

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 operational meaning beyond the schema: the token must be the latest one from the previous successful response on every follow-up, and the uid is reused per application. This clarifies the chaining protocol, not just the field types.

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 opens with a specific verb and resource set: read the bound or cancelled umbrella policy record, its documents, and any cancellation/refund/support history. That is enough for an agent to know what comes back. It never names a concrete sibling (e.g. homeowners_consumer_policy or umbrella_consumer_service), so the differentiation from adjacent tools stays implicit.

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 trigger conditions: use after Coverage Cat reports a policy on file, or after a service request is opened. It also implies an exclusion by saying to stay on this follow-up tool rather than switch to delegated tools. There is no explicit when-not-to-use or named alternative tool, which keeps it short of a 5.

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 the mutation/idempotency/safety profile, but the description adds substantial behavior the annotations cannot express: stateless MCP requiring an `intake_access_token`, reuse of uid plus latest token on follow-ups, legacy host session authorization, token privacy, and the 'not submitted yet' reassurance rule. These are real operational constraints an agent needs before invoking.

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 intent is front-loaded, but the paragraph bloats: the full list of nine sibling tool names is enumerated mid-sentence, the canonical key list is repeated from the schema, and 'Do not send vehicles rows before submission' appears twice. Several sentences about tokens and sessions could be compressed 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?

With an output schema present and rich per-parameter descriptions, the description covers the handoff contract, token lifecycle, sandbox mode, and consent timing well enough to call correctly. It stops short of describing failure modes or what the returned uid/token look like, but the output schema carries that.

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 spells out canonical intake keys, the `sandbox` semantics, the `field_estimates` provenance rows, and the `idempotency_key` retry contract, so the description largely restates rather than extends. The one added nuance ('do not send vehicles rows before submission') is useful but appears verbatim in the schema too, making the baseline 3 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 opening sentence names the verb (prefill handoff), the resource (umbrella consumer intake), and the exact triggering condition ('shopper wants Coverage Cat to shop for, compare, or buy umbrella insurance and no operator bearer token is present'). It also distinguishes this entry point from follow-up siblings by naming the whole consumer-operated subset that comes after it.

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 sequencing guidance: call this on cold start before asking the questionnaire, then stay on the named follow-up tools (`consumer_intake_issues`, `consumer_intake_patch`, `umbrella_consumer_select`, ...). It also states a clear when-not ('Coverage Cat will not resume or expose a prior consumer umbrella draft based on email alone') and the sandbox rehearsal path.

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 destructiveHint=true and idempotentHint=true, and the description supplies real added context: stateless MCP 2026-07-28 requires the token on every follow-up, tokens must stay private, legacy hosts may hold hidden session authorization, and consent must be personally collected before submitting. It still never explains what the destructive side effect actually commits (e.g., that the application moves into a post-choose/bind track or whether the choice is revocable), which is the one behavioral fact an agent most needs before calling a destructive tool.

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 rules are operational rather than filler, but the paragraph is dense and repeats itself ("keep tokens private and stay on this same MCP follow-up tool" vs. the closing clause about not switching to delegated tools), and consent/privacy instructions are interleaved with flow control instead of grouped. A reader must parse several sentences before reaching the one action the tool performs.

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 nine-parameter destructive tool with nested consent objects and an output schema, the description covers the full lifecycle: preconditions, token handling, per-offer consent branches, the Monoline MVR disclosure requirement, and the retry path after a consent-required response. Return values are handled by the output schema, so nothing an agent needs in order 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%, so baseline would be 3, but the description adds cross-parameter conditional meaning the schema cannot express: when intake must carry selection_guidance.same_reply_requirements, when monoline_mvr_consent is separately required versus credit_consent, and when to resend the same idempotency_key after a failure. That is genuine semantics beyond field-level descriptions.

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 opening sentence places the tool in the flow ("continue the consumer-prefill umbrella flow after quotes are ready") and the body makes the action clear through selection_token and selection_confirmed, so an agent can tell it apart from umbrella_consumer_bind, umbrella_consumer_attach and umbrella_consumer_payment. It never states the verb/resource as plainly as "select the shopper's chosen umbrella offer," so the core action must be inferred from the parameters rather than read in the first clause.

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 concrete preconditions (quotes ready, reuse uid and intake_access_token), conditional branches (selection_guidance.same_reply_requirements on the first select call, Monoline offers requiring the separate MVR authorization, consent-required responses requiring a retry with receipts), and a clear exclusion (do not switch to delegated tools). It does not name the specific sibling tools for downstream steps, so routing is implied rather than explicit.

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 destructiveHint=true, idempotentHint=true, and openWorldHint=false, so the safety profile is largely covered. The description adds genuinely useful context beyond that: the stateless MCP 2026-07-28 token requirement, token privacy handling, and the rule not to describe a request as completed until Coverage Cat confirms the outcome. It doesn't spell out precisely what the destructive action affects (e.g. coverage ending), leaving a small gap.

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 critical guidance (preview before confirm, token reuse) is front-loaded, which is good. However, the middle is cluttered with overlapping directives: 'Keep tokens private and stay on this same MCP follow-up tool' is immediately followed by 'Stay on the same consumer-operated MCP subset after bind,' which adds little and is ambiguous.

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 and rich annotations, the description need not explain return values, and it covers the stateful follow-up flow, approval gate, and completion-confirmation rule. What is missing is any note on what actually happens to the underlying policy after a cancellation is opened, which matters for a destructive tool.

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 every parameter including confirm_request, idempotency_key, and requested_effective_date is documented in the schema itself. The description's parameter guidance (reuse uid and intake_access_token, confirm after approval) largely restates what the schema already says. Baseline 3 is appropriate when the schema carries this much detail.

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 opens with a specific verb+resource: preview or open a cancellation, refund, or support request for a consumer umbrella policy. That is clearly distinct from siblings like umbrella_consumer_policy, umbrella_consumer_bind, and umbrella_consumer_payment, which handle other stages. It doesn't explicitly name an alternative tool, so it stops just short of a 5.

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 an explicit two-step workflow: preview first, then send confirm_request: true only after the shopper approves the preview. It also states the follow-up sequencing (reuse uid and the latest intake_access_token from the previous successful response) and tells the agent to stay on this follow-up tool rather than drifting to another one.

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 the safety profile (read-only, idempotent, non-destructive, closed-world), so the bar is lower. The description adds real context beyond them: it discloses the output contents (arithmetic target, additional limit needed, and the $0–$10M scenario ladder) and attaches an explicit disclaimer that the result is not a quote or a legal determination — a behavioral trait no annotation conveys.

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?

Three sentences, front-loaded with the calculation inputs before the return values and the scope caveat. Every sentence earns its place; the enumerated scenario ladder is slightly verbose but informative about output shape.

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 and the description still summarizes returns, annotations cover safety, and parameters are fully documented. The remaining gap is the absence of any routing guidance relative to umbrella_calculator and umbrella_underlying_limit_check in a crowded umbrella namespace.

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% with five well-documented parameters, so the schema already carries the semantics. The description restates the input categories and hints at their relationships (protected assets must be independently confirmed, income allowance optional, underlying limit is the lowest applicable), but adds nothing the schema doesn't already say more precisely.

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 pair: comparing how much umbrella coverage to consider from named inputs (net worth, protected assets, income allowance, underlying limit). The scope boundary ('planning, not a quote or a determination of legally exposed assets') further sharpens what the tool is. It does not, however, name or contrast with close siblings such as umbrella_calculator or umbrella_underlying_limit_check, so the agent must infer the split.

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?

The description implies the tool is for planning-level comparison and explicitly excludes quoting and legal exposure determination, which helps an agent know what not to expect. But it never states conditions that select it over umbrella_calculator or umbrella_underlying_limit_check, leaving the sibling choice 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 read-only, idempotent, closed-world, non-destructive, so the safety bar is low. The description still adds real behavioral context: unknown limits are not filled in or guessed, each required increase is returned separately, and it explicitly disclaims claim-payout and eligibility determinations — scoping the output beyond what annotations convey.

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?

Four short sentences, front-loaded with the action and scope, then the input constraint, then the output caveat. Dense and nearly waste-free; only slight overlap between the required-from-quote instruction and the identical wording already in the schema.

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 needn't be described, and annotations cover the safety profile. For a 9-parameter, conditionally-structured tool the description supplies the key operational caveats (quote-sourced requirements, unknown stays unknown, per-increase results), though it could have noted the structure-dependent required fields it only gestures at.

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%, including the enum explanation and the null-vs-zero distinction, so the schema already carries the semantics. The description reinforces the 'from the quote, not assumed minimums' intent but adds no format or structural detail beyond that, so 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 verb (check) and resource (an underlying policy against a specific umbrella quote's liability requirements), and enumerates the covered policy types. It does not name a sibling like umbrella_limit_planner or umbrella_calculator, so the agent must infer the boundary from the 'requirements from that quote' framing rather than an explicit contrast.

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?

The description gives input-sourcing guidance ('supply requirements from that quote, not assumed carrier minimums') and a data-handling rule ('missing current limits stay unknown'), which shape how to call it. It gives no explicit when-to-use-this-instead-of signal against the several umbrella siblings, leaving the routing inference to the agent.

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