VeteranHQ

Prepare for a C&P exam

prepare_cp_exam

Read-onlyIdempotent

Use this when a veteran has a VA compensation and pension examination scheduled for a condition and wants to know what it involves. Returns the examination type and typical length, what the examiner does, the questions examiners commonly ask, the Disability Benefits Questionnaire sections that apply, records worth bringing, common misunderstandings about the exam, and prompts for reporting symptom frequency and functional impact accurately. For a condition with a guide on file it also returns the rating tiers for that condition's diagnostic code, which is what the examiner's findings are scored against; any other condition returns a general exam guide. Educational reference about the examination process. It does not schedule, reschedule or contact VA, and the examiner's findings and VA decide the rating.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`condition`	Yes	Condition being examined (e.g., "PTSD", "knee", "sleep apnea", "tinnitus").
`currentRating`	No	Current rating if already rated (for increase exams). Optional.

TDQS

A4.4/5.0

Behavior5/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, but the description adds substantial behavioral detail beyond those flags: exactly what content is returned, that it is an 'Educational reference,' and that it does not affect scheduling or the rating decision. It also discloses the condition-specific behavior (rating tiers vs. general guide). This is rich, honest transparency.

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?

The description is longer than a simple two-sentence example, but each clause adds distinct information: trigger, outputs, conditional behavior, and limitations. It is front-loaded with the 'Use this when' trigger and then organized as a flowing list of return items. It earns its length given the tool's breadth, though it could be tightened slightly without losing meaning.

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 no output schema and only two simple parameters, the description is exceptionally complete. It covers what the tool returns, when to use it, the condition-specific variance, its educational non-actionable nature, and the relationship to the rating decision. There are no obvious gaps for an agent to invoke or interpret the tool correctly.

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 'condition' and 'currentRating' have clear descriptions (e.g., 'Condition being examined' and 'Current rating if already rated (for increase exams)'). The tool description does not add new parameter-level details; it references 'rating tiers' and 'diagnostic code' but doesn't elaborate on the parameters themselves. Baseline 3 applies because the schema carries the meaning.

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 specific trigger: 'Use this when a veteran has a VA compensation and pension examination scheduled for a condition...' and enumerates concrete outputs (exam type, typical length, examiner actions, sample questions, DBQ sections, records, misunderstandings, symptom prompts). This clearly distinguishes it from sibling tools like calculate_combined_rating or search_legal_authority by focusing solely on exam preparation.

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?

The description explicitly states when to use it ('Use this when a veteran has a VA compensation and pension examination scheduled...'), provides context for different conditions (guide on file vs. general exam guide), and includes a clear exclusion: 'It does not schedule, reschedule or contact VA.' It does not name specific alternative tools, but the 'Use this when' phrasing plus the negative scope gives strong usage direction.

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?