Skip to main content
Glama

Coverage Cat

Homeowners consumer prefill handoff

homeowners_consumer_prefill
Idempotent

Preferred homeowners MCP entry point when a shopper wants Coverage Cat to shop for, compare, or buy homeowners insurance and no operator bearer token is present. On a cold start, ask only for the user's name, email, property address, and whether this should be standard homeowners, condo, or landlord coverage. If that coverage type is still unknown, ask the shopper to reply with exactly one of standard homeowners, condo, or landlord, then assemble the fullest homeowners application from user-controlled context and property sources before handing off to Coverage Cat. Recover core shopper and occupancy facts such as date of birth, marital status, and owner-occupied vs new-purchase from that context before relying on Coverage Cat's estimated review card. Stay on the same consumer-operated MCP subset through review, long-lag quote polling, quoted-offer selection, bind follow-up, and post-bind policy/support follow-up. Homeowners quotes or carrier bind follow-up may take up to 48 hours, so keep polling and keep the registered customer email on file for notifications. When the submitted homeowners flow gets a new follow-up question, consumer_intake_issues returns conversation.messages plus conversation.reply_pending so the agent can answer it in chat with consumer_intake_patch and message_reply. 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. Coverage Cat cannot collect first-party homeowners payment in chat. Any insurer payment or signing link must be sent directly to the customer's own email inbox on file, and the agent can only use those links if it has access to that same customer email. On the review turn, tell the shopper explicitly that the application is not submitted yet and present gathered details or remaining items as 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].

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
intakeYes
field_estimatesNo
idempotency_keyNoOptional retry key for homeowners_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 soft-credit consent on the direct review turn.

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

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

Annotations only give readOnlyHint=false, openWorldHint=false, idempotentHint=true. The description adds substantial undisclosed behavior: 48-hour quote/bind lag requiring continued polling, session preservation semantics, the consumer_intake_issues/reply_pending follow-up loop, the prohibition on collecting payment in chat, email-inbox-only link delivery, and review-turn presentation rules. This is far beyond what the 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.

Conciseness3/5

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

The purpose and entry condition are front-loaded, but the body is a dense wall of prose mixing behavioral rules with very granular formatting directives (the `*` / `* = estimated` placement). Most sentences carry real rules, yet the volume and some repetition reduce readability for an agent skimming for the call contract.

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

Completeness5/5

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

For a complex multi-turn prefill/handoff flow, the description covers entry conditions, data gathering, follow-up handling, retry semantics, payment constraints, and presentation rules. An output schema exists, so return values need not be explained, and nothing critical for correct invocation is missing.

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

Parameters3/5

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

Schema coverage is 50%; idempotency_key and credit_consent_pending are already documented in the schema, while the two nested objects (intake, field_estimates) are undocumented there. The description partially compensates by listing the facts to gather into intake (name, email, address, coverage type, DOB, marital status, occupancy) and by referencing estimated values tied to field_estimates, so it adds meaningful but incomplete parameter meaning.

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 first sentence names a specific verb+resource (the homeowners MCP entry point for shopping/comparing/buying homeowners insurance) and a distinguishing condition (no operator bearer token present). It is immediately separable from siblings such as homeowners_consumer_bind, homeowners_consumer_select, and umbrella_consumer_prefill.

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 exactly when to enter this tool (cold-start shopper wanting Coverage Cat to shop/compare/buy, no operator token), what to ask for on cold start, and how to route within the flow (prefill → review → quote polling → select → bind → post-bind). It also names the fallback path (retry with latest intake_access_token) and forbids the wrong alternatives (raw HTTP, asking for credentials).

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