PolicyVera insurance quotes

Correct your details after a request was sent

correct_my_details

DestructiveIdempotent

Corrects the person's details on PolicyVera after a request was sent (a birth date, a VIN, a driver, the phone, the insured-today answer), through the same doors as the site's profile. Pass requestId with only what changes (changes: e.g. a driver's name and corrected dateOfBirth, or a vehicle's VIN on file and its corrected fields): PolicyVera rebuilds the rest from what it holds. Or pass requestId with the request's whole draft (draft: the same home and coverage lines); a car's VIN is corrected through changes (vin and newVin). The first call checks it the way preview_quote_request does and answers what changes, what will be on file and a correctionId, writing nothing; the second, with the same input, the correctionId and personConfirmed, records it. It sends no new request: the insurance agents working the person's open requests read the live details, and PolicyVera tells them when the person's details, people, cars or home change (not the insured-today answer or the person's own license). The note to the insurance agents stays as sent: send_message carries anything new.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "correct_my_details"
  }
}

Input Schema

Name	Required	Description
`draft`	No	With requestId, instead of changes: the request's whole draft with the corrections (the same coverage and home).
`changes`	No	Only what changes; everything else stays as PolicyVera has it for this request.
`requestId`	No	The open request to correct (check_quotes lists them); with changes or with the whole draft.
`correctionId`	No	From the first call on this same draft; with personConfirmed it writes.
`zipConfirmed`	No
`confirmedChecks`	No	The ids of the preview's ask checks that the person said are right, in their own words in this conversation. Only an ask check closes this way; a refuse or needed check stays open until the draft answers it.
`personConfirmed`	No	true: the person said yes to what will be on file, in this conversation.

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedNov 7, 2026
- changedInput schema / properties / changes / properties / vehicles / items / properties / year / maximum
```
Previous value: -2027New value: +9007199254740991
```
- changedInput schema / properties / draft / properties / insuredHomeFacts / properties / yearBuilt / maximum
```
Previous value: -2027New value: +9007199254740991
```
- changedInput schema / properties / draft / properties / vehicles / additionalProperties / items / properties / year / maximum
```
Previous value: -2027New value: +9007199254740991
```
First observedNov 4, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Annotations declare destructive/openWorld/idempotent, and the description adds substantial behavior beyond them: the first call writes nothing and returns a correctionId, the second call with the same input plus correctionId and personConfirmed commits it. It also discloses which changes notify agents (details, people, cars, home) and which do not (insured-today answer, the person's own license).

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?

Content is front-loaded and every sentence carries unique information, but the prose is dense with nested parentheticals ("changes: e.g. a driver's name and corrected dateOfBirth, or a vehicle's VIN on file and its corrected fields") that slow parsing. It earns its length but could be tightened into bullets or shorter clauses.

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 a 7-param nested schema with two large input objects and no output schema, the description covers the full workflow: mode selection, preview vs commit, required confirming inputs, side effects on agents, and notification boundaries. An agent has everything needed to call it correctly.

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 already high (86%), so many params are documented in the schema. The description nonetheless adds real relational meaning: requestId is mandatory context, changes and draft are mutually exclusive representations of the same correction, vin identifies a vehicle on file while newVin is the fix, and correctionId/personConfirmed gate the write. It does not fully explain confirmedChecks or zipConfirmed.

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 names a specific verb and resource ("corrects the person's details on PolicyVera") and scopes it precisely to "after a request was sent", listing the editable fields (birth date, VIN, driver, phone, insured-today). It also distinguishes itself from siblings: preview_quote_request for the checking behavior and send_message for anything new to tell the agents.

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 use it (post-submission corrections), the two alternative input modes (changes vs whole draft) with the rule that VIN fixes go through changes with vin and newVin, and the two-step sequence (first call checks, second records). It also says what the tool does NOT do (sends no new request; note stays as sent — use send_message).

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

All PolicyVera insurance quotes tools Inspect

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

Need Help?