New York State Workers' Compensation Hub

NY average weekly wage (§14)

calculate_aww

Read-onlyIdempotent

The average weekly wage from earnings in the year before the accident: earnings_method "steady" (WCL §14(1)–(2): earnings ÷ days worked × 200/260/300 for a 4-/5-/6-day week, 365 for 7) or "irregular" for new, seasonal or irregular work (§14(3)–(4): earnings ÷ weeks worked). With a date of accident it also gives the weekly rate. 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.

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": {
      "earnings_method": "<earnings_method>",
      "total_earnings": "<total_earnings>"
    },
    "name": "calculate_aww"
  }
}

Input Schema

Name	Required	Description
`days_worked`	No	steady: days actually worked in the period.
`weeks_worked`	No	irregular: weeks actually worked.
`days_per_week`	No	steady: days normally worked each week (1–4 use the 200 multiplier).
`total_earnings`	Yes	Total gross earnings in the period, in dollars.
`earnings_method`	Yes
`date_of_accident`	No	Optional: adds the weekly rate.

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 13, 2026

TDQS

A3.9/5.0

Behavior3/5

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

Annotations already cover read-only, idempotent, closed-world, non-destructive behavior, so the safety profile is structured. The description adds real context beyond that: the calc-core engine, 'it never estimates', the 'missing' status path that returns needed inputs and calculates nothing, and citation/attorney-review flagging. That is moderate value-add over annotations, not rich enough for a 4 given how much the annotations already 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 computation, then method branches, then scoping and return behavior. Dense but nearly every sentence adds information; the engine/credibility clause ('the engine behind the app, the website calculators and the Pro Workspace') is the least load-bearing part.

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?

No output schema exists, so the description carries the return contract and does so fully: figures, rate year used, formulas with citations and attorney-review flags, plus the not-legal-advice notice. It also documents the missing-input behavior, so an agent knows what happens with incomplete parameters.

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 high (83%), so the baseline would be 3, but the description adds computation semantics the schema lacks: the 200/260/300 multipliers for 4-/5-/6-day weeks, 365 for 7 days, and earnings ÷ weeks for irregular work. It ties days_worked and weeks_worked to their respective modes, which helps an agent route inputs correctly.

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

Purpose4/5

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

States a specific verb and resource ('The average weekly wage from earnings in the year before the accident') and names the two computational modes with statutory citations. It does not, however, distinguish itself from the very similar sibling calculate_aww_with_adjustments, which an agent would plausibly confuse it with.

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?

Gives clear selection logic between the two modes: 'steady' for §14(1)–(2) earnings ÷ days × multiplier, and 'irregular' for 'new, seasonal or irregular work'. It also scopes the tool to New York State only. It stops short of explicitly excluding or deferring to sibling calculators.

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

All New York State Workers' Compensation Hub 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.