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 for rating intervertebral disc syndrome on incapacitating episodes, 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. 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
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.4/5.0
Behavior3/5

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

Annotations already declare readOnly, idempotent, non-destructive behavior, so the safety profile is covered. The description adds substantial behavioral context beyond that: window semantics with a one-day exclusion edge case, weekend/holiday inclusion, the physician-prescribed bed rest requirement, and the tier being an estimate rather than a decision. This earns a 3 rather than higher only because some of this overlaps with what the schema already specifies.

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?

Long and dense but front-loaded with the usage condition and organized around window logic, outputs, and exclusions. Slight redundancy (restating the bed rest rule that the schema also carries) keeps it from a 5.

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 takes on the burden of describing returns (window, per-period breakdown, tier, employer-leave workday count) and the threshold fields. It also covers legal scope limits, so nothing an agent needs to call or interpret the result is missing.

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%, so the baseline is 3. The description adds interpretive meaning beyond the schema by clarifying that only physician-prescribed bed rest periods count toward a tier and that weekend/holiday days inside an episode count toward calendar duration, reinforcing why the boolean and date fields behave as they do.

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 concrete action (totals the calendar duration of incapacitating episodes inside a 12-month window) tied to a specific legal basis (38 CFR 4.71a, diagnostic code 5243). An agent can distinguish this from generic rating calculators in the sibling list 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 Guidelines5/5

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

Opens with an explicit trigger (veteran supplies episode dates and the question involves the 4.71a IVDS formula/DC 5243) and closes with explicit exclusions (does not decide FMLA entitlement, does not apply outside DC 5243). When-to-use and when-not are both stated, not inferred.

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