The Comp Desk Builder

NY award for benefit periods (CCP)

calculate_ccp_award

Read-onlyIdempotent

What is owed for one or more benefit periods (types TT total, TP partial with a disability %, RE reduced earnings with weekly earnings), the way The Comp Desk's CCP/Award calculator works it out: weeks from the dates (both ends count; a period starting the day the last ended counts it once; weeks rounded down to the tenth by default), each period's rate within the max and min, and the total award. With prior_payments (0 if none) it adds the claimant's money, the 15% fee exact to the cent, the OC-400.1 amount rounded down to $5 and the net; an employer reimbursement out of the whole award is split as 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>",
      "periods": "<periods>"
    },
    "name": "calculate_ccp_award"
  }
}

Input Schema

Name	Required	Description
`aww`	Yes	Average weekly wage before the injury, in dollars (gross).
`periods`	Yes
`prior_payments`	No	Optional: dollars already paid on these periods (0 if none). Adds the fee and net.
`weeks_rounding`	No	Optional; default tenth.
`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).

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 13, 2026

TDQS

A3.5/5.0

Behavior4/5

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), so the description is not carrying that burden. It adds real behavior: the tool never estimates, returns status "missing" plus the full list of still-needed inputs and calculates nothing, and returns rate year, citations flagged for attorney review, and a not-legal-advice notice. It also discloses the builder-key auth requirement, which is not in the annotations. Only the fee/rounding mechanics of the OC-400.1 and reimbursement split are described without stating limits or error modes beyond the missing-input case.

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?

It is front-loaded with the substantive answer and the calculation mechanics, which is good, but the second half repeats the same provenance claim twice ('the engine behind the app, the website calculators and the Pro Workspace' and 'Same engine the Pro Workspace tiles call through CD.Calc'), and the first sentence is a long chain that is hard to parse. Several clauses earn their place; the engine-branding repetition does not.

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 seven-parameter tool with a nested periods array and no output schema, the description covers the return contents (figures, rate year, formulas with citations, disclaimer) and failure behavior (status "missing"). It explains the three period types and how weeks are derived. Remaining gap is the absence of any guidance on what the tool does not cover or how the detailed sibling differs.

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 goes further on the load-bearing optional parameters: prior_payments drives the 15% fee, OC-400.1 rounding to $5, net, and employer reimbursement; the employer reimbursement is split 'as on SLU', which the schema does not say; and weeks_rounding's default of tenth is restated with the effect of date-inclusive counting. It does not add syntax detail for prior_counsel_fees beyond what the schema states.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose3/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description names a specific operation and resource: computing what is owed for one or more NY benefit periods, with the period types (TT/TP/RE) enumerated. But it never distinguishes itself from the sibling calculate_ccp_award_detailed, which an agent will see in the same catalog and cannot disambiguate from this text. The purpose is clear, but sibling differentiation is absent.

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?

Guidance is implied rather than stated: 'New York State only' scopes jurisdiction, and the prior_payments note tells the agent when the fee/net path activates. There is no explicit when-to-use versus the _detailed sibling, and no statement of prerequisites beyond 'needs your builder key'. Usable, but the agent must infer the routing decision.

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?