VeteranHQ

Check a 12-month absence window

calculate_rolling_window

Read-onlyIdempotent

Use this when a veteran supplies dates of incapacitating episodes and the question involves the 38 CFR 4.71a formula for rating intervertebral disc syndrome on incapacitating episodes, diagnostic code 5243. Totals the calendar duration of those episodes inside the 12-month window ending on a reference date. That formula bands on total calendar duration in weeks, so weekend and holiday days inside an episode count, and only periods flagged as bed rest prescribed by a physician count toward a tier. Returns the window, a per-period breakdown, the tier the flagged episodes would support, and a separate employer-leave workday count that plays no part in that tier. The tier it reports is an estimate from the episodes supplied. It does not decide FMLA entitlement and does not apply to conditions rated outside diagnostic code 5243.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`referenceDate`	No	The reference date for the 12-month rolling window (YYYY-MM-DD). Defaults to today. Typically the anticipated C&P exam date. Must be a real calendar date; an unparseable value is rejected.
`absencePeriods`	Yes	Array of absence periods. Each must have at least a startDate.

TDQS

A4.6/5.0

Behavior5/5

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

Annotations cover readOnly/idempotent/destructive hints, but the description adds substantial behavioral context: calendar-duration banding ('weekend and holiday days inside an episode count'), the bed-rest requirement, and the estimate caveat ('The tier it reports is an estimate'). It even discloses the non-role of the employer-leave workday count in the tier, which is precisely the kind of counterintuitive behavior an agent needs to know. No contradiction with annotations.

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?

Six sentences that flow logically: usage context → computation → calculation semantics → return values → caveats → exclusions. Each sentence earns its place, and the length is justified by regulatory complexity. Minor tightening possible (e.g., the estimate sentence could merge with the returns sentence), but nothing is wasted.

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?

With no output schema, the description correctly takes on the burden of specifying return values ('window, a per-period breakdown, the tier... and a separate employer-leave workday count'). It also covers edge-case behavior, regulatory grounding, and what it does NOT cover. For a tool with deeply nested parameter semantics and no output schema, this is complete.

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 100% with exceptionally rich per-parameter descriptions (reversed-range rejection, dayCount override, bed-rest semantics). The description adds linkage between parameters and outcomes—e.g., that calendar-duration banding is what makes dayCount count weekends and holidays, and that only physicianPrescribedBedRest-flagged periods feed the tier. Baseline 3 with a small uplift for connecting the parameters to the regulatory formula.

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 uses a specific verb+resource: 'Totals the calendar duration of those episodes inside the 12-month window ending on a reference date,' grounded in a precise regulatory formula (38 CFR 4.71a, DC 5243). It clearly differentiates from siblings—none of the nine sibling tools compute rolling windows—and the generic name is disambiguated by the detailed purpose.

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?

Front-loads the trigger: 'Use this when a veteran supplies dates of incapacitating episodes and the question involves the 38 CFR 4.71a formula...'. Explicit exclusions are given ('does not decide FMLA entitlement,' 'does not apply to conditions rated outside diagnostic code 5243'). Only minor gap: no alternative tool is named by name, though no sibling is a natural substitute.

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

All VeteranHQ tools Inspect

Try in Browser

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.5/5.0

Disambiguation5/5

Each tool targets a distinct VA disability operation — analyzing rating gaps, combining ratings, calculating rolling windows, checking presumptive eligibility, comparing criteria, computing retroactive pay, finding secondary conditions, looking up rates, preparing for exams, and searching legal authority. No two tools overlap in purpose; the 'calculate_*' trio is differentiated by input (percentages vs. episodes) and domain (combined rating vs. disc syndrome).

Naming Consistency5/5

All tool names follow a clear verb_noun snake_case pattern: analyze_, calculate_, check_, compare_, compute_, find_, lookup_, prepare_, search_. The verbs are semantically appropriate ('calculate' for numeric computation, 'check' for eligibility, 'lookup' for rate tables), and there are no mixed conventions or vague verbs like 'run' or 'do'.

Tool Count4/5

The server advertises 10 tools, but only 9 are listed. 9 tools is a well-scoped count for a VA disability rating assistant—each covers a distinct workflow step. The discrepancy may indicate a missing tool description in the input, so I deduct slightly for the listing mismatch, but the count itself is appropriate.

Completeness4/5

The surface covers rating analysis (gap, combined, rolling window), eligibility (presumptive), criteria search, pay estimation, secondary conditions, rate lookup, exam prep, and legal research. Notable gaps: no tool for filing a claim or appeal, no direct 'get rating schedule' without a specific diagnostic code, and no tool for calculating effective dates or handling denials. However, the core rating and compensation lifecycle is well covered.

Resources

Need Help?