PolicyVera insurance quotes

Upload your current policy

upload_policy_document

Destructive

Puts a document the person gave you or that you hold for them (a declarations page or an auto ID card: PDF, JPEG or PNG; an iPhone HEIC photo goes through get_upload_link, whose page converts it) through PolicyVera's own upload and read, exactly as the site's upload does. The file goes on the person's PolicyVera profile. When they send a request for that kind of coverage, the insurance agents on the request can open the file, confirmed or not; confirming tells the agents that the values PolicyVera read are right. When you can send a file to a web address, pass sizeBytes (and sha256 when you can) without base64: PolicyVera answers a one-file upload address; PUT the file's exact bytes there, then call again with its storageKey. Otherwise pass the bytes as base64 (small files only); a chat that can do neither uses get_upload_link. read_policy_document then returns what PolicyVera read.

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": {
      "filename": "<filename>",
      "mimeType": "<mimeType>"
    },
    "name": "upload_policy_document"
  }
}

Input Schema

Name	Required	Description
`line`	No	The coverage this policy is for, when the person said it.
`base64`	No	The file's bytes, base64: small files only (about 3 MB). Leave it out and pass sizeBytes to get an upload address instead.
`sha256`	No	The file's SHA-256 as lowercase hex, when you can compute it: PolicyVera then spots a file already on the person's profile.
`filename`	Yes	The file's name, with its extension.
`mimeType`	Yes	The file's type: application/pdf, image/jpeg or image/png.
`sizeBytes`	No	The file's size in bytes: with no base64, PolicyVera answers a one-file upload address for it.
`storageKey`	No	From the upload address's answer, after the file's exact bytes are PUT there: records the file and starts PolicyVera's read.

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 4, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Goes well beyond the annotations (destructiveHint=true, openWorldHint=true) by disclosing what actually happens: the file attaches to the person's PolicyVera profile, agents on a matching coverage request can open it whether confirmed or not, sha256 enables duplicate detection, and base64 is capped at roughly 3 MB. This is the kind of workflow and side-effect context annotations cannot carry.

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?

Front-loaded with the core action and the file-type caveat before the upload-mechanism branching, with every clause carrying information. The single dense paragraph and long parenthetical sentences make it heavier to scan than necessary, but little is genuinely wasted.

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?

With no output schema, the description covers the outcome (file stored on the profile, then read by PolicyVera) and points to read_policy_document for the read result. All seven parameters including the optional line and sha256 are given operational context, so an agent can pick a path and invoke 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 100%, so the baseline is 3, but the description adds real meaning the schema lacks: sizeBytes and storageKey are described as a two-step handshake (get an address, PUT exact bytes, call again with the key), and sha256 is framed as a dedupe signal rather than just a hash. It does not explain the line enum values beyond the schema, keeping it from a 5.

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 ("puts a document ... through PolicyVera's own upload and read") and names where the file lands. It explicitly distinguishes itself from the siblings it could be confused with, naming get_upload_link for HEIC photos and read_policy_document for the resulting read.

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 an explicit decision tree: if you can PUT to a web address use sizeBytes/sha256 then storageKey; if not, use base64 for small files; if neither, use get_upload_link. It also states when to use confirm_policy_document implicitly by explaining what confirming tells the agents.

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?