VeteranHQ

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, and returns an empty result for a code that is not in the criteria table. It is not a lookup of what a rating pays and it does not combine ratings.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`diagnosticCode`	Yes	VA diagnostic code (e.g., "8100" for migraines, "5260" for knee).

TDQS

A4.5/5.0

Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the description adds useful context: it returns results sorted highest percentage first, includes condition name/body system/38 CFR reference, and returns an empty result for unknown codes. No contradiction with annotations.

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

Conciseness5/5

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

The description is three well-structured sentences: usage trigger, output breakdown, and explicit exclusions. It is front-loaded, concise, and every sentence adds value without fluff.

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?

For a single-parameter read-only tool with no output schema, the description adequately explains return format, sorting, and empty-result behavior. It also clarifies what the tool is not for, making it complete for the agent's decision-making.

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 coverage is 100% and the schema provides an example. The description reinforces that the parameter should be a diagnostic code, not a condition name, which adds clarity beyond the schema but does not introduce new parameters or details.

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 clearly states the tool returns VASRD rating criteria for a given diagnostic code, including condition name, body system, and 38 CFR reference, at every tier. It explicitly differentiates from sibling tools by noting it takes a code rather than a condition name and is not a pay lookup or rating combiner.

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 opens with 'Use this when a veteran names a VA diagnostic code and wants the rating criteria for it' and explicitly states what it does NOT do ('not a lookup of what a rating pays and it does not combine ratings'), which implicitly directs users to alternative tools for those tasks.

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

All VeteranHQ tools Inspect

Try in Browser

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.5/5.0

Disambiguation5/5

Each tool targets a distinct VA disability operation — analyzing rating gaps, combining ratings, calculating rolling windows, checking presumptive eligibility, comparing criteria, computing retroactive pay, finding secondary conditions, looking up rates, preparing for exams, and searching legal authority. No two tools overlap in purpose; the 'calculate_*' trio is differentiated by input (percentages vs. episodes) and domain (combined rating vs. disc syndrome).

Naming Consistency5/5

All tool names follow a clear verb_noun snake_case pattern: analyze_, calculate_, check_, compare_, compute_, find_, lookup_, prepare_, search_. The verbs are semantically appropriate ('calculate' for numeric computation, 'check' for eligibility, 'lookup' for rate tables), and there are no mixed conventions or vague verbs like 'run' or 'do'.

Tool Count4/5

The server advertises 10 tools, but only 9 are listed. 9 tools is a well-scoped count for a VA disability rating assistant—each covers a distinct workflow step. The discrepancy may indicate a missing tool description in the input, so I deduct slightly for the listing mismatch, but the count itself is appropriate.

Completeness4/5

The surface covers rating analysis (gap, combined, rolling window), eligibility (presumptive), criteria search, pay estimation, secondary conditions, rate lookup, exam prep, and legal research. Notable gaps: no tool for filing a claim or appeal, no direct 'get rating schedule' without a specific diagnostic code, and no tool for calculating effective dates or handling denials. However, the core rating and compensation lifecycle is well covered.

Resources

Need Help?