PolicyVera insurance quotes

Preview the request before sending

preview_quote_request

Read-only

Checks the draft the way PolicyVera's own site checks a request before its Send, and tells which of the picked insurance agents will receive it (and who is dropped, and why). Nothing is saved or sent. ready: false lists the checks, each in its words (said): refuse (the site would refuse it, or it cannot be true), needed (the site asks it before sending), ask (it looks off; the person's own answer closes it, its id in confirmedChecks). Insurance agents quote from exactly what is sent. ready: true returns every line of theyWillSee (what the insurance agents will see) and the consent paragraph, for send_quote_request. For a person already on PolicyVera, what their profile holds can stay out of the draft (requirements, signed in, marks it done): the preview fills it from the profile and names it in filledFromProfile.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "draft": "<draft>"
    },
    "name": "preview_quote_request"
  }
}

Input Schema

Name	Required	Description
`draft`	Yes
`zipConfirmed`	No	Only after this door asked about the ZIP and the person said it is right.
`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.
`confirmDuplicate`	No	Only after this preview named an open request this one repeats and the person said to request again.

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedNov 7, 2026
- 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.2/5.0

Behavior5/5

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

Goes well beyond the readOnly/non-destructive annotations by explaining that nothing is persisted, and by disclosing the two response modes: ready:false yields refuse/needed/ask checks with the site's own wording, ready:true yields every line of theyWillSee plus the consent paragraph. It also names filledFromProfile behavior for existing users, which is real behavioral context the annotations cannot 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?

Front-loads the core idea well, but the body is dense and overloaded with parenthetical jargon ('each in its words (said)', 'theyWillSee') and a long trailing sentence about profile-fill that could be trimmed. The information is useful but not tightly edited.

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 tool with no output schema, the description does the necessary work of explaining both response shapes and what send_quote_request consumes. Nested-draft nuances such as duplicate confirmation and ZIP confirmation are left to the schema, which covers them adequately.

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?

At 75% schema coverage the schema already documents most parameters, and much of the description's parameter talk (profile backfill, ask-check ids) is restated from schema descriptions. It does connect ask checks to confirmedChecks, but says nothing about zipConfirmed or confirmDuplicate, which are explained only 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?

States a specific verb and resource (checks the draft request) and immediately scopes it against the sending tool: 'Nothing is saved or sent' and the ready:true output is 'for send_quote_request'. An agent can tell this apart from send_quote_request without opening either schema.

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?

Makes the workflow position explicit: run this before send_quote_request, and use the ask-check ids in confirmedChecks when the person affirms them. It also carves out the profile-fill case. It never names a competing read-only check tool (e.g. requirements) as an alternative, so 4 rather than 5.

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?