Skip to main content
Glama

Analyze a rating gap

analyze_rating_gap
Read-onlyIdempotent

Use this when a veteran gives a condition name and the VA disability percentage currently assigned for it, and wants that percentage compared against the VASRD criteria. It describes what the criteria require; only VA decides a rating. Returns the tier that matches the current percentage, the next tier above it, and every higher tier on file for that condition, with the criteria each one requires. It reports when the condition is already at the highest documented tier, and when no criteria are on file for that condition name. documentedTiers lists the tier percentages on file for the condition, and currentPercentIsDocumentedTier says whether the percentage supplied is one of them: false means the figure does not correspond to a tier in the criteria on file, which happens when the rating came from a formula or a code this search did not resolve. For a veteran at zero percent, zeroPercentBasis is "documented" when a zero percent row for the code is on file and "unresolved" when the complete tier set could not be established, and zeroPercentUnderFourThirtyOne answers whether 38 CFR 4.31 is what assigns that zero: false where the schedule on file provides a zero percent evaluation or the rating is compensable, and null where the question is open. A null there is an unanswered question rather than a finding that 4.31 applies, because the rule turns on what the schedule provides for the code and this tool reads the criteria on file rather than the omissions in the schedule.

Input Schema

NameRequiredDescriptionDefault
conditionNameYesCondition to analyze (e.g., "PTSD", "Lumbar strain").
currentPercentYesCurrent VA rating percentage for this condition (e.g., 30, 50, 70).

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.1/5.0
Behavior5/5

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

Annotations only cover the safety profile (readOnly, idempotent, non-destructive). The description adds substantial behavioral context beyond that: exactly which tiers are returned, the already-highest-tier case, the no-criteria-on-file case, and the semantics of null versus false. This is unusually thorough for a tool with no output schema.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded well: the usage trigger and returned values come first. But the closing discussion of zeroPercentBasis and zeroPercentUnderFourThirtyOne is dense and partially redundant ('A null there is an unanswered question rather than a finding that 4.31 applies' restates the preceding sentence), costing clarity.

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?

There is no output schema, so the description carries the burden of explaining return values, and it does so comprehensively, including the highest-tier report and the missing-criteria edge case. Nothing an agent needs to call and interpret this tool is absent.

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 description coverage is 100% for both parameters, so the baseline is 3. The description does add meaning to currentPercent by tying it to documentedTiers (whether the supplied figure corresponds to a real tier), but gives no new syntax or format detail for conditionName beyond the schema examples.

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: compares a veteran's assigned VA percentage against VASRD criteria and returns tiers. The scope (conditions with a current percentage) is clear. However it never distinguishes itself from the sibling compare_rating_criteria, which sounds like an overlapping capability, so sibling differentiation is missing.

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?

Explicitly opens with a when-to-use trigger ('Use this when a veteran gives a condition name and the VA disability percentage currently assigned for it'). It gives clear positive context but names no when-not conditions and never points to compare_rating_criteria or other siblings as alternatives.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources