LLPRO Campus

Compare payer remits to contract rates

underpayment_audit_compare

Read-onlyIdempotent

Compare commercial payer remits to your contract rates and list the underpayments. Send contract_rates (code, optional 2-character modifier, rate per unit in US dollars) and remit_lines (your own line_id, code, optional modifier, units, paid, optional patient_responsibility or the payer's allowed amount). Get back, per line, expected vs actual and the shortfall, totals in cents, the sources (your two lists, with the labels and dates you gave) and a signed record. Free. Arithmetic only: no model, no outside lookup, nothing stored. Up to 200 rates and 200 lines per call. Do NOT send patient names, dates of birth or member, account or record numbers: only your own row numbers as line_id. It does not read contracts, assign codes, or give billing, coding or legal advice, and it cannot say a payer is wrong, only that the numbers differ from the table you supplied.

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": {
      "contract_rates": "<contract_rates>",
      "remit_lines": "<remit_lines>"
    },
    "name": "underpayment_audit_compare"
  }
}

Input Schema

Name	Required	Description
`tolerance`	No	US dollars per line up to and including which a difference is ignored. Default 1.00, at most 1000.
`remit_label`	No	Optional name of the remit batch, echoed back as a source.
`remit_lines`	Yes
`contract_label`	No	Optional name of the contract, echoed back as a source.
`contract_rates`	Yes
`contract_effective_date`	No	Optional date the rates took effect (YYYY-MM-DD), echoed back.

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 13, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Annotations already declare readOnly, idempotent, non-destructive and closed-world, and the description adds substantial context on top: 'Free. Arithmetic only: no model, no outside lookup, nothing stored', hard batch limits, and a PII prohibition naming exactly which identifiers must not be sent. It also discloses the key limitation that results mean numbers differ from the supplied table, not that the payer is wrong.

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 result, then inputs, then returns, then limits and prohibitions — a sensible order with no filler sentences. It is dense in places (the parenthetical field lists) but every sentence carries information an agent needs.

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, and the description compensates by describing the return shape: per-line expected vs actual and shortfall, totals in cents, echoed sources with labels and dates, and a signed record. Combined with the limits and privacy constraints, nothing material is left for the agent to guess.

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?

With 67% schema coverage, the description usefully restates the shape of both lists, including that the modifier is 2 characters, that the rate is per unit in US dollars, and that either patient_responsibility or the payer's allowed amount may be supplied. It omits tolerance, the label fields, and contract_effective_date, leaving those entirely to 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?

The description opens with a specific verb and resource ('Compare commercial payer remits to your contract rates') and states the output ('list the underpayments'), which distinguishes it from anything else in the sibling set. It also enumerates what the two input lists contain, so an agent knows exactly what the tool consumes and produces.

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?

Usage context is clear and bounded: up to 200 rates and 200 lines per call, arithmetic only, and explicit exclusions ('does not read contracts, assign codes, or give billing, coding or legal advice', 'cannot say a payer is wrong'). It does not name an alternative tool or a when-not-to-use-this condition beyond the scope caveats, so it stops short of a 5.

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?