The Comp Desk Builder

NY schedule loss of use (SLU) award

calculate_slu_award

Read-onlyIdempotent

A schedule loss of use award for one or more scheduled members: weeks on the schedule × loss of use % × the weekly rate for the date of accident, plus any protracted healing period credit (weeks at temporary total beyond the longest healing period, §15(4-a)). With prior_payments (0 if none) it adds the money moving, the 15% attorney fee rounded down to $5 (the OC-400.1 amount) and the net. With an employer reimbursement it splits the money and the fees between claimant and employer, exact to the cent; the fee on the reimbursement comes from the claimant's money when it is enough. Optional prior-counsel fee split. No 130-week credit on SLU. New York State only. Computes with The Comp Desk calc-core (the engine behind the app, the website calculators and the Pro Workspace); it never estimates. If an input is missing it returns status "missing" with every input still needed and calculates nothing. Returns the figures, the rate year used, the formulas with their citations (each flagged with whether it has been attorney-reviewed), and the not-legal-advice notice. Needs your builder key. Same engine the Pro Workspace tiles call through CD.Calc, so a figure here matches the app to the cent.

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": {
      "aww": "<aww>",
      "date_of_accident": "<date_of_accident>",
      "body_parts": "<body_parts>"
    },
    "name": "calculate_slu_award"
  }
}

Input Schema

Name	Required	Description
`aww`	Yes	Average weekly wage before the injury, in dollars (gross).
`body_parts`	Yes	Each scheduled member and its schedule loss of use percentage. Members: arm, hand, leg, foot, thumb, index/middle/ring/pinky finger, great toe, other toe, eye, one ear, both ears.
`prior_payments`	No	Optional: dollars of this award already paid (0 if none). Adds the fee and net.
`date_of_accident`	Yes	Date of accident (injury), YYYY-MM-DD. Only a full date the user gave; never a guessed one.
`prior_counsel_fees`	No	Optional. Dollar amount of the fee apportioned to each prior counsel (one or two). The current attorney gets the rest of the fee.
`employer_reimbursement`	No	Optional employer reimbursement (REIMB ER) out of the award: { "amount": dollars } or { "amount_unknown": true } when it is still TBD. Needs prior_payments (0 if none).
`weeks_at_temporary_total`	No	Optional: weeks paid at temporary total, for the protracted healing period credit.

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 13, 2026

TDQS

A3.8/5.0

Behavior4/5

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

Well beyond the annotations, which only declare a safe, deterministic read: the description discloses the auth requirement ('Needs your builder key'), the missing-input contract (status 'missing' with every input still needed and nothing calculated), the never-estimates guarantee, and the return payload (figures, rate year, cited formulas flagged attorney-reviewed, not-legal-advice notice). It does not cover rounding or edge-case failures beyond that, so it stops short of a 5.

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-loaded and information-dense, but it repeats itself: the calc-core pedigree is stated twice ('the engine behind the app, the website calculators and the Pro Workspace' and again as 'Same engine the Pro Workspace tiles call through CD.Calc'), and cent-level accuracy is asserted three separate ways. Trimming that duplication would cost nothing.

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 7-parameter nested-input calculation tool with full schema coverage and no output schema, this covers auth, failure mode, determinism, scope and return contents — nearly everything an agent needs. A few details, such as the allowed schedule-member spellings, live only in the schema, but the description does not need to duplicate them.

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 100%, so the schema already carries the baseline. The prose does add meaning the schema lacks — prior_payments triggering fee-and-net output, the employer reimbursement splitting money and fees to the cent with a priority rule, and the 15% attorney fee rounded down to $5 — but these are stated as output effects rather than as parameter-by-parameter guidance.

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 names a specific calculation ('A schedule loss of use award for one or more scheduled members'), then spells out the formula (weeks × loss of use % × weekly rate) and the optional add-ons. Scoping constraints ('New York State only', 'No 130-week credit on SLU') further separate it from the other calc_* siblings, so an agent can identify it without opening the schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage context is implied rather than stated: the NY-only scope and the absence of a 130-week credit tell the agent where the tool applies, and the missing-input behavior tells it what happens on bad data. But no alternative is named — an agent with an ROM percentage must guess that calculate_slu_percent_from_rom comes first, and no when-not-to-use case is given.

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

All The Comp Desk Builder 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?