Skip to main content
Glama

VeteranHQ

by app.veteranhq
OverviewDiscussionsAdmin

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 VA uses to rate intervertebral disc syndrome on incapacitating episodes, diagnostic code 5243. The tier it reports is an estimate from the episodes supplied, and it does not decide FMLA entitlement or apply to conditions rated outside diagnostic code 5243. Totals the calendar duration of those episodes inside the 12 months ending on a reference date: the window opens the day after the same date one year earlier and closes on the reference date, with both ends counted, so an episode that began exactly 12 months before that date falls outside it by one day. 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. Inside ivdsThresholdAnalysis, calendarDaysBelow60PercentThreshold and weeksBelow60PercentThreshold report how far the counted episodes fall below the 6-week duration that bands at 60 percent under that formula. They measure the reported history against a threshold in the regulation; they are not a target, since a veteran does not accumulate bed rest to reach a rating.

Input Schema

NameRequiredDescriptionDefault
referenceDateNoThe 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.
absencePeriodsYesArray of absence periods. Each must have at least a startDate.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changed
    • changedInput schema / properties / absencePeriods / items / properties / dayCount / description
      Previous value: -"Total CALENDAR days absent in this period, weekends included. Use this when the veteran reports \"20 days between March and December\" instead of exact dates. If provided, startDate/endDate define the outer span and dayCount overrides the calendar days counted within it. Do NOT convert a work-day figure: ask the veteran for calendar days."New value: +"Total CALENDAR days absent in this period, weekends included, for a period reported as a count (for example \"20 days between March and December\") rather than as exact dates. If provided, startDate/endDate define the outer span and dayCount overrides the calendar days counted within it. A work-day total alone does not establish calendar duration: this value is a reported calendar-day total, not an estimate converted from work days."
    • changedInput schema / properties / absencePeriods / items / properties / endDate / description
      Previous value: -"End date of the absence period in YYYY-MM-DD format. If omitted, assumed same as startDate (single day). Must be on or after startDate: a reversed range is rejected rather than counted, so ask the veteran again instead of guessing the order."New value: +"End date of the absence period in YYYY-MM-DD format. If omitted, assumed same as startDate (single day). Must be on or after startDate; a reversed range is rejected rather than counted."
    • changedInput schema / properties / absencePeriods / items / properties / physicianPrescribedBedRest / description
      Previous value: -"True only when a physician PRESCRIBED bed rest for this period and treated the veteran, which is what 38 CFR 4.71a Note (1) requires of an incapacitating episode. Optional; when omitted or false the period is reported as a plain absence and contributes NOTHING to the IVDS tier. Never set it true from a work absence, a sick day, or self-directed rest."New value: +"True only when a physician PRESCRIBED bed rest for this period and treated the veteran, which is what 38 CFR 4.71a Note (1) requires of an incapacitating episode. Optional; when omitted or false the period is reported as a plain absence and contributes NOTHING to the IVDS tier. A work absence, a sick day, or self-directed rest without a physician's prescription does not meet that definition."
  2. First observed

TDQS

A4.6/5.0
Behavior5/5

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

Annotations only cover the safe-read profile (readOnly, idempotent, non-destructive); the description adds substantial behavior beyond that: inclusive window boundaries with the one-day edge case, that weekends/holidays count, that only physician-prescribed bed rest tiers, and a warning that the ivdsThresholdAnalysis fields are a regulatory threshold, not a rating target.

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?

The trigger constraint is front-loaded and every sentence is load-bearing, but the block is dense and long, with the threshold-field explanation and boundary edge-case detail making it heavier than strictly necessary for tool selection.

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 must describe returns, and it does: the window, per-period breakdown, the supported tier, the separate employer-leave workday count, and the ivdsThresholdAnalysis subfields. An agent has enough to call it correctly.

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 coverage is 100% and the schema descriptions already carry the calendar-vs-workday distinction, the bed-rest flag semantics, and the date rules; the description largely restates these, so it adds little meaning beyond the structured fields. Baseline 3 is appropriate when the schema does the heavy lifting.

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?

States a specific verb (totals calendar duration of incapacitating episodes) and resource (the 12-month rolling window for 38 CFR 4.71a / diagnostic code 5243), and explicitly scopes out FMLA entitlement and conditions rated outside DC 5243, so it is distinguishable from siblings like analyze_rating_gap or compute_retroactive_pay.

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

Usage Guidelines5/5

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

Front-loads an explicit trigger ('Use this when a veteran supplies dates of incapacitating episodes and the question involves the 38 CFR 4.71a formula') and names what it is not for (FMLA, conditions outside DC 5243), leaving no inference about when to select it.

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

All VeteranHQ toolsInspect
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