Skip to main content
Glama

VeteranHQ

by app.veteranhq
OverviewDiscussionsAdmin

Calculate combined VA rating

calculate_combined_rating
Read-onlyIdempotent

Use this when a veteran has two or more VA disability rating percentages and wants the combined rating. Applies the 38 CFR 4.25 Combined Ratings Table procedure: pairwise combination in severity order, whole-percent rounding after each step, then conversion to the nearest 10. Returns combinedRating as an object holding both figures under their own names: rounded is the rating after that conversion, raw is the Combined Ratings Table value before it. The arithmetic for each step comes back alongside them. The optional bilateral argument tags the ratings that affect both arms or both legs; when it is supplied and one pair has a compensable rating on each side, 38 CFR 4.26 applies to those ratings first: they combine with each other, 10 percent of that value is added rather than combined, and the result enters the 4.25 combination as one disability. Without that argument no bilateral factor is applied. The 38 CFR 4.26(d) comparison across eligible groupings is exhaustive here for up to 16 tagged compensable ratings; past that the response carries combinedRatingWithoutBilateralFactor in place of combinedRating, labelled as a figure the bilateral factor has not been applied to, with a note that VA and accredited representatives compute that factor. The result differs from adding the percentages and from a simple product. It reports what 38 CFR 4.25 and 4.26 yield for the percentages supplied, not what VA has assigned, and it does not evaluate special monthly compensation.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
ratingsYesArray of individual disability rating percentages (0-100), e.g., [70, 50].
bilateralNoOptional. Tags the ratings that affect a paired extremity, so 38 CFR 4.26 can be applied: those ratings are combined with each other first, 10 percent of that value is added (not combined), and the result enters the 4.25 combination as one disability. The factor needs a compensable rating on both sides of one pair (both arms or both legs); tag every rating that affects an arm or a leg and the tool applies the factor only where the regulation allows it. Tagging more than 16 compensable ratings is accepted and answered, but past that the 38 CFR 4.26(d) comparison across eligible groupings is not exhaustive here, so the result carries the 4.25 combination of every rating supplied under combinedRatingWithoutBilateralFactor instead of a combined rating, and says where the complete calculation comes from.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed5 schema fields changed
    • addedInput schema / properties / bilateral
      Added value: +{
+  "description": "Optional. Tags the ratings that affect a paired extremity, so 38 CFR 4.26 can be applied: those ratings are combined with each other first, 10 percent of that value is added (not combined), and the result enters the 4.25 combination as one disability. The factor needs a compensable rating on both sides of one pair (both arms or both legs); tag every rating that affects an arm or a leg and the tool applies the factor only where the regulation allows it. Tagging more than 16 compensable ratings is accepted and answered, but past that the 38 CFR 4.26(d) comparison across eligible groupings is not exhaustive here, so the result carries the 4.25 combination of every rating supplied under combinedRatingWithoutBilateralFactor instead of a combined rating, and says where the complete calculation comes from.",
+  "items": {
+    "additionalProperties": false,
+    "properties": {
+      "extremity": {
+        "description": "The extremity that rating affects.",
+        "enum": [
+          "left-arm",
+          "right-arm",
+          "left-leg",
+          "right-leg"
+        ],
+        "type": "string"
+      },
+      "index": {
+        "description": "Position in the ratings array of the rating this entry describes (0-based).",
+        "maximum": 19,
+        "minimum": 0,
+        "type": "integer"
+      }
+    },
+    "required": [
+      "index",
+      "extremity"
+    ],
+    "type": "object"
+  },
+  "maxItems": 20,
+  "type": "array"
+}
    • changedInput schema / properties / ratings / description
      Previous value: -"Array of individual disability rating percentages (0–100), e.g., [70, 50]."New value: +"Array of individual disability rating percentages (0-100), e.g., [70, 50]."
    • addedInput schema / properties / ratings / items / maximum
      Added value: +100
    • addedInput schema / properties / ratings / items / minimum
      Added value: +0
    • addedInput schema / properties / ratings / maxItems
      Added value: +20
  2. First observed

TDQS

A4.6/5.0
Behavior5/5

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

Annotations already establish read-only/idempotent/non-destructive, and the description adds substantial extra behavior: the step-by-step algorithm, the shape of the return (rounded vs raw figures plus per-step arithmetic), the bilateral-factor edge case, and the >16-rating fallback field. It also discloses limitations (regulatory output only, no SMC).

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?

It is a dense block, but the domain is genuinely complex and the trigger is front-loaded before the mechanics. Nearly every sentence carries required information; only minor tightening (bulleting the 4.25/4.26/fallback branches) would improve scanability.

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 fully compensates by enumerating the returned fields (combinedRating.rounded, .raw, arithmetic, and the fallback combinedRatingWithoutBilateralFactor) and their meaning. Nothing an agent needs to invoke and interpret the call 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, but the description meaningfully expands on the optional bilateral argument beyond the schema: how tagged pairs combine, the 10-percent addition rule, the both-sides compensable requirement, and the >16-tagged cap behavior. This adds real interpretive value over the field text.

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 and resource (compute the combined VA disability rating) and names the governing regulation (38 CFR 4.25). It clearly distinguishes the result from naive addition or multiplication and from the separate compute_retroactive_pay / lookup_compensation_rate siblings.

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 an explicit trigger ('Use this when a veteran has two or more VA disability rating percentages and wants the combined rating') and boundaries (does not report what VA assigned, does not evaluate special monthly compensation). It does not, however, route to a named alternative sibling when the input is a single rating or a pay question.

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