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 percentage currently assigned for it, and wants that percentage compared against the VASRD criteria. 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. It describes what the criteria require; only VA decides a rating.

Input Schema

TableJSON 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 already declare read-only, idempotent, non-destructive behavior, and the description adds substantial context beyond them: it enumerates the return shape (current-tier match, next tier above, all higher tiers with criteria), and documents edge-case behavior for highest documented tier, missing criteria, undocumented percentages, and zero-percent handling including null semantics. It also adds the important scope caveat that "only VA decides a rating."

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?

The usage trigger is correctly front-loaded, but the body is a dense, run-on block that mixes return-field semantics into a single paragraph and re-explains the null/wording distinction in several clauses. Given no output schema this detail is defensible, but readability and structure suffer.

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 full burden of explaining return values and does so thoroughly: it covers the tier comparison output, the documentedTiers/currentPercentIsDocumentedTier fields, and the zeroPercentBasis and zeroPercentUnderFourThirtyOne branches with their interpretive caveats. Nothing essential to understanding the result is missing.

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%: both conditionName and currentPercent are documented with examples in the schema. The description adds only a paraphrase ("condition name and the percentage currently assigned"), with no extra syntax, format, or range guidance, so the baseline of 3 is appropriate.

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?

The description states a specific verb+resource+scope: it compares a currently assigned condition percentage against VASRD criteria and returns the matching tier plus all higher tiers. An agent can tell what it produces. It does not, however, differentiate itself from the sibling compare_rating_criteria, which sounds closely related, so it falls short of a 5.

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?

It gives an explicit trigger: use it "when a veteran gives a condition name and the percentage currently assigned for it, and wants that percentage compared against the VASRD criteria." That is a clear usage context, but it names no alternatives (e.g., compare_rating_criteria) and no when-not-to-use exclusions, so it stops short of a 5.

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