Free, read-only VA disability help: claims Q&A with VA.gov sources, BDD checklist, rating math.
Scored across 3 tools
Each tool serves a distinct purpose: general Q&A, BDD checklist, and combined rating calculation. There is minimal overlap, though the broad Q&A tool could theoretically answer questions covered by the specialized tools.
All names use snake_case, but patterns vary: ask_va_benefits_question and estimate_combined_rating are verb phrases, while bdd_separation_checklist is a noun phrase. This mixed convention reduces predictability.
Three tools cover the core functions of a VA disability benefits assistant: answering questions, BDD preparation, and rating math. The count is well-scoped for this focused domain.
The surface covers common VA disability needs, including a catch-all Q&A tool, but lacks tools for specific operations like checking individual claim status, finding VSOs, or explaining appeals. These are minor gaps given the knowledge-base nature.
Answer a general VA disability benefits or claims question from Valor AI's reviewed knowledge base, with official VA sources. Read-only. Never send personal records.
| Name | Required | Description | Default |
|---|---|---|---|
| question | Yes | A general VA benefits or claims question. Do not include personal details. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so safety is covered. The description still adds real value beyond them: answers are grounded in a reviewed knowledge base with official VA sources, and the 'Never send personal records' directive gives an explicit privacy constraint for the agent to enforce.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences, front-loaded with purpose, then provenance, then the privacy constraint. No filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter, no-output-schema lookup tool, the description supplies the sourcing model (reviewed KB, official VA sources) that shapes how the agent should present results, plus the privacy constraint. It could say more about answer format or limits, but nothing essential for correct invocation is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There is a single parameter with 100% schema description coverage, so the schema already documents the input fully; baseline is 3. The description's 'Do not include personal details' merely echoes the schema's own note without adding format, length, or phrasing guidance.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (answer) and resource (general VA disability benefits or claims question) and names the provenance of the answer (Valor AI's reviewed knowledge base, official VA sources). It doesn't explicitly contrast with the sibling tools bdd_separation_checklist or estimate_combined_rating, though the 'general question' framing implicitly sets it apart from those specific calculators.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The word 'general' implies this is the tool for open-ended questions rather than the two specific sibling tools, but the description never states when to prefer this over them or what kinds of questions fall outside its scope. Usage is inferable rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return the Benefits Delivery at Discharge (BDD) prep checklist and where the service member is relative to the 180 to 90 day window.
| Name | Required | Description | Default |
|---|---|---|---|
| daysUntilSeparation | No | Approximate days until separation from active duty (negative if already separated). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false, so safety behavior is fully covered by structured data. The description usefully adds that the return includes both a checklist and a window-position assessment, but says nothing about formatting or the edge behavior implied by the negative-day range.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence that names the return value and the key domain constraint with no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter, read-only, closed-world tool with no output schema, the description conveys what comes back and the window framing. Only a brief note on output shape or what happens outside the window is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% so the schema already documents daysUntilSeparation. The description goes beyond it by supplying the domain-relevant 180-to-90-day window threshold, which gives the numeric input concrete meaning the schema alone does not.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('Return') and a concrete resource (the BDD prep checklist plus the member's position in the 180-90 day window). It is clearly distinguishable from ask_va_benefits_question and estimate_combined_rating, though it never names or contrasts them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is only implied by the topic (BDD eligibility/prep). There is no statement of when to call this versus the sibling tools and no preconditions or exclusions, so the agent must infer the trigger.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Combine individual VA disability ratings using the official VA math (38 CFR 4.25, bilateral factor 4.26) and show each step.
| Name | Required | Description | Default |
|---|---|---|---|
| ratings | Yes | Individual disability ratings to combine. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds real value beyond that: it names the governing math (38 CFR 4.25, bilateral factor 4.26) and promises a step-by-step breakdown, which tells the agent the response is explanatory rather than a bare number. It does not describe the exact output format, but that is a minor omission for a deterministic calculator.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence with zero filler: it identifies the action, the authoritative method, and the output style. Nothing could be removed without losing information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only, deterministic calculation tool with a fully documented input schema, the description supplies the essential missing context: the algorithmic basis and the fact that intermediate steps are returned. The only gap is that no output schema exists and the response shape is only loosely characterized.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and all nested fields (rating step-of-10 constraint, side, extremity for the bilateral factor) are documented inline in the schema. The description adds no parameter-level meaning beyond that, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Combine individual VA disability ratings') and pins the exact methodology with citations to 38 CFR 4.25 and the bilateral factor in 4.26. The domain is clearly distinct from 'ask_va_benefits_question' and 'bdd_separation_checklist', so an agent can route without ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied by the purpose: an agent can infer it should call this when it has a set of individual ratings and needs the combined value. However, there is no explicit when-to-use statement, no guidance on when this is preferable to asking a benefits question, and no stated prerequisites or edge-case handling.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
ask_va_benefits_questionbdd_separation_checklistestimate_combined_ratingVeterans benefits and VA claims reference: VA disability ratings, compensation rates, 38 CFR search
Real Board of Veterans' Appeals outcome data for VA disability claims. No key needed.
900,000+ Board of Veterans' Appeals decisions: VA outcomes, grant rates, PACT Act, ratings.
Read-only Social Security COLA data, calculations, history, and official source links.
Add one secure layer between your agents and this server.
