Skip to main content
Glama
Sign In

SecondAppraisal Total-Loss Intake

by com.secondappraisal
OverviewDiscussionsAdmin

Submit a total-loss situation

submit_total_loss_intake
DestructiveIdempotent

Submit a vehicle owner's total-loss situation to SecondAppraisal on their behalf. Minimum: one of customer.phone / customer.email, your agent self-identification, and a consent.attestation. Returns a receipt with customer_confirmation_url (one tap confirms), a relayable customer_message, an optional preliminary market read, contact_policy (we will email/text a welcome and a person will call to confirm the request came from the customer or their agent), and pricing — the consultation is free; if the owner wants more, Appraisal Research is $199 (paid up front, no guarantee) or the Appointed Appraiser Service (our Appraisal Research, appointment as the customer's appraiser under the policy's appraisal clause, determining the amount of loss with the insurer's appraiser, and the appraisal award letter) is $495 with a $25 discount for customers you send ($470; a card HOLD, not a charge). The guarantee applies once SecondAppraisal accepts the consultation and serves as the customer's appraiser: if the appraisal award, or a higher offer the insurer makes instead, is less than $1,000 above the insurer's offer on the day SecondAppraisal accepted, the fee is waived and the hold released. An umpire's fee, if one is needed, is separate. The $25 applies to the Appointed Appraiser Service (representation) only. You may quote pricing verbatim; payment always happens on our site by the customer's own click (checkout links appear once they have confirmed) — never collect card details. Read customer_message to the user verbatim.

Input Schema

NameRequiredDescriptionDefault
lossNoWhen and where the loss happened.
agentYesWho is calling. Required — an intake without self-identification is refused.
offerNoThe insurer's position so far, if any.
consentYesConsent basis. Attestation wording version 2026-09-16.1.
vehicleNoThe vehicle. A VIN (or plate + plate_state) is best; year/make/model works too.
customerYesThe vehicle owner. At least one of email / phone is required; everything else is optional.
external_refNoYour reference id; echoed in every response.
idempotency_keyNoAny unique string per logical submission; a replay returns the original receipt.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.4/5.0
Behavior5/5

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

Annotations declare destructiveHint=true and idempotentHint=true; the description goes further by detailing the receipt contents, contact policy, pricing structure with discounts, free consultation scope, guarantee terms, card hold vs charge, and a strict rule against collecting card details. This is rich context beyond the annotations.

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

Conciseness4/5

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

The content is front-loaded with the core action and minimum requirements, then proceeds to describe outputs and pricing. It is dense but well-organized; however, the pricing section is lengthy and could be trimmed or structured as a list for easier scanning.

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?

Given the complexity of the tool, nested schema, lack of output schema, and annotations, the description provides complete information on what happens after submission, including receipt fields, contact policy, and pricing. An agent has everything needed to call it correctly and explain outcomes to a user.

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 description coverage is 100%, so the schema already documents all eight parameters and nested fields comprehensively. The description adds some meaning about the receipt and pricing, but does not provide additional parameter-level guidance beyond 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 description opens with a specific verb and resource ('Submit a vehicle owner's total-loss situation') and names the receiving service. It is clearly distinct from the read-oriented siblings like get_intake_status and get_preliminary_estimate.

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

Usage Guidelines4/5

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

It lists minimum requirements (one contact, agent self-identification, consent attestation) and explains consent modes via the schema. It does not explicitly say when to use this versus the sibling lookup tools, but the action-oriented nature makes the intent clear.

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

All SecondAppraisal Total-Loss Intake toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources