Skip to main content
Glama

Coverage Cat

Consumer intake patch and submit

consumer_intake_patch
Idempotent

Patch a consumer-prefill homeowners or umbrella handoff in chat. 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. This submit/update tool stays in the default consumer-operated MCP subset; do not switch to delegated tools when no operator bearer key is present. For homeowners, use intake to add context-backed or property-backed answers while keeping the user out of a questionnaire until the one-time review. After a homeowners application is submitted, this same tool can also answer insurer or shopper follow-up surfaced under conversation.messages by sending message_reply and, when Coverage Cat returned one, reply_to_message_id. For umbrella, use the staged review turn to send only the explicitly missing shopper-owned details plus any corrections to reviewed facts, and set confirm_submission only on that same final review confirmation. 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. If the staged review shows a wrong estimated umbrella count from context, patch the canonical umbrella_details.* count field before you show the final review. Do not send vehicles rows on this pre-submit patch; actual vehicle details stay in the later bind-stage flow if a selected offer requires them. Normalize shopper birthdays from MM-DD-YYYY to YYYY-MM-DD before you send them. Recover context-backed answers before you depend on Coverage Cat's estimated review card, tell the user the application is not submitted yet until you actually submit it, present gathered details or remaining items as short labeled bullets or sections rather than a prose paragraph, and 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]. Do not ask for umbrella credit consent here.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
uidYes
intakeNoTop-level intake edits. For umbrella, send only missing shopper-owned details, corrections, or canonical umbrella count fixes such as umbrella_details.motorized_vehicle_count. Do not send vehicles rows on this pre-submit patch. 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.
message_replyNoHomeowners post-submit only. Send the reply text Coverage Cat should deliver in-thread when consumer_intake_issues surfaced an insurer or shopper follow-up under conversation.messages.
field_estimatesNoUmbrella-only estimate metadata for inferred values included in the same patch. Omit it unless you are certain each field path matches a current umbrella review field.
idempotency_keyNoOptional retry key for consumer_intake_patch. 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.
confirm_submissionNoSet true only on the single final review turn.
intake_access_tokenNoOptional bearer fallback for this same MCP follow-up tool when your host cannot preserve Coverage Cat's hidden shopper session. Reuse the latest token from the previous successful Coverage Cat response and never show it to the shopper.
reply_to_message_idNoOptional homeowners post-submit target from conversation.messages[].message_id when Coverage Cat returned a specific message to answer in-thread.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
uidYesCoverage Cat intake uid for the current handoff.
lineNo
offersNo
policyNo
reviewNoStructured review card or selected-offer review block.
schemaNoSupplemental schema hints for homeowners review payloads.
statusYes
sandboxNoTrue when Coverage Cat is returning consumer sandbox test data rather than a live shopper workflow.
supportNo
uploadedNo
documentsNo
expires_atNoWhen the current consumer handoff expires.
offers_urlNoCoverage Cat browser URL for the selected offer or offer-tracking page.
payment_uiNo
next_actionNoA structured hint for the next allowed tool or endpoint action.
payment_urlNoCoverage Cat browser URL for secure payment fallback.
post_chooseNoStructured post-choose state after a quoted umbrella offer is selected.
conversationNo
review_itemsNo
review_tokenNoOpaque review token for delegated review-style submit paths.
detail_statusNo
known_summaryNoStructured facts Coverage Cat can safely summarize at this stage.
next_questionNoThe current shopper-owned question bundle or bind-stage question.
offer_summaryNo
payment_setupNo
preview_tokenNoOpaque bind-preview token for the next homeowners bind confirmation.
missing_fieldsNoStructured missing-value hints for homeowners pre-submit review.
payment_statusNo
pending_fieldsNoStructured missing-value hints for umbrella pre-submit review.
selected_offerNo
uploaded_countNo
field_estimatesNo
service_previewNo
service_requestNo
purchase_previewNo
response_summaryNo
review_estimatesNo
service_requestsNo
agent_instructionsNo
poll_after_secondsNo
selection_guidanceNoGuidance for completing an offer choice in one shopper-facing reply.
compare_details_urlNoCoverage Cat browser URL for compare-details follow-up.
intake_access_tokenNoShort-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.
notification_channelNo
user_action_requiredNo
application_submittedNo
required_upload_typesNo
credit_consent_questionNo
payment_collection_supportedNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4/5.0
Behavior4/5

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

Annotations declare readOnlyHint=false, openWorldHint=false, idempotentHint=true, and the description adds genuine context beyond them: hidden session preservation, a bearer-token fallback, 24-hour idempotent replay, and submission gating via confirm_submission. Much of the remaining text is shopper-facing presentation guidance rather than tool behavior, which keeps it from 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.

Conciseness2/5

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

The description is a single sprawling block that mixes session mechanics, key naming rules, formatting directives, and retry policy. It is not front-loaded by topic and is difficult to parse; the useful core sentence is immediately buried by a long tail of procedural instruction.

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 nested-schema tool with an output schema and idempotency behavior, the description covers session handling, submission gating, field conventions, and post-submit follow-ups. Return values are handled by the output schema, so the main coverage gaps are structural rather than missing concepts.

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 88%, so the baseline is 3, but the description adds real meaning: canonical umbrella key names (`address.street`, `net_worth_numeric`, `umbrella_details.motorized_vehicle_count`), keys to avoid (`street`, `drivers_license_number`, `net_worth`), birthday normalization, and how to translate raw limits into the banded enum. This exceeds what the schema conveys.

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

Purpose4/5

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

The opening sentence gives a specific verb and resource: 'Patch a consumer-prefill homeowners or umbrella handoff in chat.' It also references sibling concepts (`consumer_intake_issues`, delegated tools) and the intake flow, but does not cleanly position itself against the prefill/select/bind siblings; the core purpose is clear though surrounded by procedural noise.

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?

Explicit usage and exclusions are present throughout: use `intake` for homeowners context-backed answers, retry with `intake_access_token` if the host cannot preserve session state, do not drop to raw HTTP or delegated tools when no operator bearer is present, and set `confirm_submission` only on the final review turn. Multiple when/when-not conditions and alternatives are named.

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