Skip to main content
Glama

Coverage Cat

Umbrella consumer prefill handoff

umbrella_consumer_prefill
Idempotent

Preferred umbrella MCP entry point when a shopper wants Coverage Cat to shop for, compare, or buy umbrella insurance and no operator bearer token is present. On a cold start, call this before asking the shopper a questionnaire. Assemble the fullest estimate you can justify from user-controlled context, let Coverage Cat stage the one-review handoff, and keep the user out of a step-by-step questionnaire. On the initial consumer umbrella handoff, prefer sending only intake; add top-level field_estimates only when you are certain each field already matches a current umbrella review field path. Use canonical consumer umbrella keys such as address.street, address.city, address.state, address.zip, license_state, license_number, approximate_asset_value or net_worth_numeric, desired_coverage_limit, required_coverage_e_limit, and vehicle_count or umbrella_details.motorized_vehicle_count for umbrella counts. Avoid top-level street/city/state/zip, drivers_license_state, drivers_license_number, net_worth, or desired_umbrella_liability_limit. Do not send vehicles rows before submission. Use vehicle_count or umbrella_details.motorized_vehicle_count for the household vehicle count; actual vehicle details are collected later only if a selected offer requires them, such as a Markel bind follow-up. Stay on the same consumer-operated MCP subset through quoted offers, declarations upload, payment_needed, optional agentic payment collection, payment_url fallback, and post-bind policy/support follow-up; do not switch to delegated tools just to reach checkout or aftercare. If you are rehearsing the shopper flow, set sandbox: true on this first prefill call only. That same consumer sandbox uid can then continue through consumer_intake_issues, consumer_intake_patch, umbrella_consumer_select, umbrella_consumer_bind, umbrella_consumer_attach, umbrella_consumer_payment, umbrella_consumer_policy, umbrella_consumer_service, and coarse consumer_status polling with synthetic quotes, uploads, payment credentials, policy outcomes, and service-request results only. Coverage Cat prefers to keep follow-up authorization in the hidden MCP shopper session after prefill, so a preserved host usually only needs uid. If your host cannot preserve that MCP session state, retry this same MCP follow-up tool with the latest intake_access_token from the previous successful Coverage Cat response instead of dropping to raw HTTP or asking the shopper for credentials. Until a later follow-up response shows quote progress, tell the shopper explicitly that the application is not submitted yet. When you summarize the staged review or remaining items, use short labeled bullets or sections rather than a prose paragraph. If any shown value is estimated, mark each estimated bullet label or value with *, include the short note * = estimated once above and once below the list, and do not prefix every estimated line with [Estimated]. Coverage Cat will not resume or expose a prior consumer umbrella draft based on email alone. Continue an existing consumer draft only through the issued uid plus the current hidden MCP session or latest intake_access_token handoff.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
intakeYesFullest currently known consumer umbrella application patch. Use canonical keys such as address.street/city/state/zip, license_state, license_number, approximate_asset_value or net_worth_numeric, desired_coverage_limit, required_coverage_e_limit, and vehicle_count or umbrella_details.motorized_vehicle_count for umbrella counts. Do not send vehicles rows before submission. current_auto_coverages is a banded enum, not free text: send one of unsure for I'm not sure; 500k/1m for $500k/$1 Million/$100k or higher; 500k/500k for $500k/$500k/$100k or $500k CSL; 300k/300k for $250k/$500k/$100k or $300k/$300k/$100k or $300k CSL; 100k/300k for $100k/$300k/$100k or lower. Coverage Cat rejects the shopper's raw limits, so translate them into the strongest band those limits fully satisfy. Underlying auto limits gate umbrella eligibility, so reserve unsure for limits the shopper genuinely does not know rather than using it to skip the translation.
sandboxNoOptional. Set true only on the first consumer umbrella prefill call when you want a fully synthetic shopper rehearsal that continues on the same consumer tool set.
field_estimatesNoOptional estimate metadata. On the initial consumer umbrella handoff, prefer omitting this unless each field path already matches a current umbrella review field.
idempotency_keyNoOptional retry key for umbrella_consumer_prefill. If you retry after a timeout or transport failure, resend the identical arguments with the same idempotency_key. Coverage Cat replays the cached successful result for 24 hours and rejects a changed payload under the same key.
credit_consent_pendingYesMust be true. Coverage Cat collects consent for a soft credit check only after an umbrella offer is chosen.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
uidYesCoverage Cat intake uid for MCP follow-up.
sandboxNoTrue when Coverage Cat is returning consumer sandbox test data rather than a live shopper workflow.
expires_atYesWhen the current consumer handoff expires.
review_summaryYesCurrent non-authoritative pre-submit checkpoint the agent may summarize before continuing in chat or opening a browser fallback. Unless a later follow-up response shows quote progress, treat this application as not submitted yet. If any shown value is estimated, mark that bullet or value with `*`, include the short note `* = estimated` once above and once below the list, and do not prefix every estimated line with `[Estimated]`.
intake_access_tokenYesShort-lived follow-up bearer. On REST, send it back as Authorization for the next `/api/intake/{uid}` call. On MCP, retry the same follow-up tool with this token only when your host cannot preserve Coverage Cat's hidden shopper session. Never display it to the shopper.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.4/5.0
Behavior4/5

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

With only three coarse annotations, the description still carries real behavioral weight: sandbox is limited to the first call, session state is preserved server-side so a host usually needs only uid, intake_access_token is the fallback credential, drafts are not resumable by email, and the application is explicitly not yet submitted. It does not, however, describe error modes or how repeated prefill calls merge into existing intake.

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

Conciseness3/5

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

Purpose is front-loaded, but the body runs long and blends tool-selection guidance with shopper-facing output formatting rules (bulleted summaries, asterisk-marked estimates) and duplicates the canonical-key list already present in the intake schema description. Some of that is necessary orchestration detail, but the density and repetition cost readability.

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

Completeness4/5

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

For a complex, multi-stage orchestration entry point with a nested intake object and an output schema, the description covers sequencing across the whole consumer tool set, sandbox behavior, credential handoff, and draft continuation. The remaining gap is what a successful response contains and how failures or re-calls behave, which the output schema only partly compensates for.

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

Parameters4/5

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 beyond the schema: it names legacy keys to avoid (top-level street/city/state/zip, drivers_license_state, drivers_license_number, net_worth, desired_umbrella_liability_limit) and cautions against sending vehicles rows early or field_estimates unless paths match. Those are field-validity rules not restated in the schema.

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

Purpose5/5

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

The opening sentence gives a specific resource and role (umbrella consumer prefill as the preferred entry point for umbrella shopping) and pins the condition that selects it (no operator bearer token present). It is distinguishable from siblings like homeowners_consumer_prefill, the umbrella_consumer_* post-prefill tools, and delegated tools by name.

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

Usage Guidelines5/5

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

It states when to call (cold start, before any questionnaire), how to behave (assemble the fullest justifiable estimate, keep the shopper out of step-by-step flow), and explicit when-nots (do not switch to delegated tools for checkout/aftercare, do not use raw HTTP, do not resume drafts on email alone, do not drop to the operator path). Alternatives and exclusions are named rather than implied.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources