Skip to main content
Glama

Compare rating criteria

compare_rating_criteria
Read-onlyIdempotent

Use this when a veteran names a VA diagnostic code and wants the rating criteria for it. Returns the VASRD criteria on file for that code at every tier, highest percentage first, with the condition name, body system and 38 CFR reference, so the findings each tier requires can be read side by side. It takes a diagnostic code rather than a condition name. A code that 38 CFR 4.71a, 4.73 or 4.124a rates in two columns, one for the dominant arm (Major) and one for the non-dominant arm (Minor), returns the regulation's own table and an empty tiers list: schedule is that table as published, with schemaVersion, variant and provenance (the eCFR edition date and the SHA-256 of the source text), every row carrying both published percentages, and scheduleText renders it with its headings, footnotes and the notes whose stated scope includes the code. Notes printed in the same table whose applicability is not established are quoted in a separate labelled section; placement alone does not establish that they apply to this code. For a neuritis or neuralgia code rated on one of those nerve scales, schedule lists each maximum with its qualifying text and ratedOnScale is the scale. The response lists every row and every maximum without choosing one, and when that table cannot be read it carries a message and a link to the eCFR section instead, even with no criteria on file. Other codes with no criteria on file return an empty result. Every response carries a source block: the 38 CFR reference for the code, a link to the current rating schedule at the publisher, and a scheduleSnapshot whose retrievedAt is the date this text was read from eCFR. That date is null for the criteria on file, with a note saying it is not recorded, so the criteria are usable as the schedule on file and the current text governs where the two differ; for a table under schedule it is the date the snapshot was read. It is not a lookup of what a rating pays and it does not combine ratings.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
diagnosticCodeYesVA diagnostic code (e.g., "8100" for migraines, "5260" for knee).

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Annotations already declare readOnlyHint=true, openWorldHint=false, idempotentHint=true, and destructiveHint=false. The description goes far beyond these by detailing edge cases (two-column codes for dominant/non-dominant arms, neuritis/neuralgia scales, no criteria on file), the source block with provenance (eCFR edition date, SHA-256), and the distinction between scheduleSnapshot dates. It also explains when tiers are empty and how notes are handled. This is rich behavioral disclosure that exceeds what annotations provide.

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 description is a single, very long paragraph with dense information. While every sentence carries relevant detail, the lack of structure (no bullets, headings, or paragraph breaks) makes it harder to scan. It is front-loaded with the primary use case, but the extensive edge-case explanations could be organized more clearly. It earns a 3 because it is comprehensive but not concise or well-structured.

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?

Given the tool's complexity and the absence of an output schema, the description must explain return values and behavior thoroughly. It covers the structure of responses (schedule, tiers, source block, scheduleSnapshot), edge cases (two-column tables, nerve scales, no criteria), and the provenance details. It also clarifies what the tool does not do. This is complete for an agent to invoke correctly without additional context.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% (the single parameter diagnosticCode is described with examples). The description adds meaning beyond the schema by explicitly stating 'It takes a diagnostic code rather than a condition name,' which is a crucial semantic distinction. It also gives examples (e.g., '8100' for migraines) in the schema, but the description reinforces the code-vs-name point and explains the implications for lookup behavior.

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?

The description opens with a clear directive: 'Use this when a veteran names a VA diagnostic code and wants the rating criteria for it.' It specifies the resource (VA diagnostic code) and the action (returns rating criteria). It also differentiates from siblings by explicitly stating 'It is not a lookup of what a rating pays and it does not combine ratings,' which rules out lookup_compensation_rate and calculate_combined_rating.

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?

The description provides explicit when-to-use guidance in the first sentence and adds exclusions: 'It is not a lookup of what a rating pays and it does not combine ratings.' It also clarifies that it takes a diagnostic code rather than a condition name, preventing misuse. Though it doesn't name sibling tools directly, the 'not' statements effectively signal when not to use this tool.

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