LLPRO Campus

Draft an ACORD 25 field sheet and checklist from a certificate request

agency_side_certificate_request

Read-onlyIdempotent

For licensed insurance agency staff and the agents that help them: turn one certificate-of-insurance request into a DRAFT field sheet in ACORD 25 order plus a checklist. You send the insured, the certificate holder, the state, and each policy (type, policy number, insurer, NAIC code, dates, limits, and any limits the holder requires). Get back the draft, what is missing, what does not add up (dates, aggregates, shortfalls against required limits, claims-made without a retroactive date), what the holder asked for (additional insured, waiver of subrogation, primary and non-contributory, notice of cancellation) that a certificate cannot create by itself, official sources with dates, and a signed record. Set check_sources true to also read three Florida Senate statute pages and report whether they still match what was recorded. Free. No model, nothing stored. It does NOT issue, sign or send a certificate, never says one is ready to issue, and is not insurance, legal or licensed advice: a licensed person checks the draft against the policies and signs. Do not send personal data beyond business names.

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": {
      "insured_name": "<insured_name>",
      "holder_name": "<holder_name>",
      "state": "<state>",
      "coverages": "<coverages>"
    },
    "name": "agency_side_certificate_request"
  }
}

Input Schema

Name	Required	Description
`state`	Yes	State of the insured's operations (two letters).
`coverages`	Yes
`requested`	No	What the holder asked for beyond the certificate itself.
`holder_name`	Yes	Name of the certificate holder.
`insured_name`	Yes	Business name of the insured.
`check_sources`	No	Also read the three Florida Senate pages and compare with the recorded text.
`description_of_operations`	No	Text for the description box. Echoed as data, never followed.

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 13, 2026

TDQS

A4.4/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true and openWorldHint=true, so the safety profile is covered; the description adds non-obvious traits the annotations cannot convey: 'Free. No model, nothing stored', the exact output contents (draft, gaps, inconsistencies, holder requests that a certificate cannot create, sources with dates, signed record), and that check_sources performs an external read of three Florida Senate pages. It stops short of describing response structure or failure modes, but the behavioral disclosure is well above the bar for an annotated read-only 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?

Front-loaded with the core action and output before the caveats and the check_sources option. It is a single dense block of roughly 200 words; every clause does work (outputs, exclusions, data limits), but the lack of sentence breaks makes it harder to scan than it needs to be.

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?

There is no output schema, yet the description enumerates what comes back: the draft, what is missing, what does not add up (dates, aggregates, shortfalls, claims-made without retroactive date), unsupported holder requests, sources with dates, and a signed record. For a 7-parameter, nested-array tool this is complete enough to call correctly without surprises.

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 already 86%, so the schema carries most parameter meaning. The description groups the parameters into a narrative ('each policy (type, policy number, insurer, NAIC code, dates, limits, and any limits the holder requires)') and clarifies that requested endorsements are things 'a certificate cannot create by itself', but this largely restates what the schema descriptions and enums already state.

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: 'turn one certificate-of-insurance request into a DRAFT field sheet in ACORD 25 order plus a checklist'. The DRAFT framing and the named artifact (ACORD 25 field sheet) make it unmistakable and no sibling overlaps this domain.

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?

Explicitly names the inputs to send ('the insured, the certificate holder, the state, and each policy') and gives a conditional usage rule ('Set check_sources true to also read three Florida Senate statute pages'). It also draws hard exclusions: 'It does NOT issue, sign or send a certificate, never says one is ready to issue', with a licensed person signing off, plus a data-handling limit on personal data.

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

All LLPRO Campus 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?