PolicyVera insurance quotes

Send the request to the picked insurance agents

send_quote_request

Destructive

Sends the request to the insurance agents the person picked, through PolicyVera's own send path, after the same checks as preview_quote_request: a check still open refuses the send and nothing is sent. It takes the person's yes to the preview they saw (personConfirmed) with the same draft, the same confirmedChecks and zipConfirmed, and the preview's previewId (a changed draft needs a new preview). Returns the request id for check_quotes.

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>",
      "personConfirmed": "<personConfirmed>",
      "personConfirmedAt": "<personConfirmedAt>"
    },
    "name": "send_quote_request"
  }
}

Input Schema

Name	Required	Description
`draft`	Yes
`previewId`	No	The previewId from the preview the person saw (ready: true) of this same draft. A preview of the same draft answers the id again and sends nothing.
`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.
`personConfirmed`	Yes	The person saw the preview and said to send.
`confirmDuplicate`	No	Only after a 'duplicate' refusal, and only if the person confirms sending again.
`personConfirmedAt`	Yes	When they said so (ISO 8601).

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

Behavior4/5

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

Annotations already declare destructiveHint=true, openWorldHint=true and idempotentHint=false, so the safety profile is partly given; the description still earns credit by disclosing that an open check refuses the send and nothing is sent, and that the draft must match the preview. It stops short of stating the post-send consequence (the request reaching real agents and not being recallable), which is the main residual gap for a destructive tool.

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?

Three dense sentences with the action and safety constraint front-loaded and the return value last; nearly every clause carries information. It is slightly clause-heavy (checks, draft identity, previewId, return id in one breath), which costs a little readability but nothing is filler.

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 destructive, nested-schema tool with no output schema, the description covers the prerequisite preview, the refusal behavior, the draft-matching rule, and the return value (the request id for check_quotes). What is missing is only the downstream consequence and where the sent request can be observed, which is minor given the rich schema and annotations.

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 86%, so the baseline is 3, but the description adds relational meaning the schema cannot: personConfirmed is the person's yes to the preview, previewId must come from the preview of this same draft, and confirmedChecks/zipConfirmed must match what the preview asked. That is genuine cross-parameter semantics, not restatement.

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 (sends the request to the picked insurance agents), plus the channel (PolicyVera's own send path), and explicitly relates it to preview_quote_request rather than leaving the agent to guess between the two siblings.

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?

Gives the exact condition for calling: the person's yes to the preview they saw, with the same draft, the same confirmedChecks and zipConfirmed, and the preview's previewId. It also names the alternative path (a changed draft needs a new preview) and points to check_quotes as the follow-up, so both when-to-use and when-not-to-use are covered.

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?