VA disability rating and compensation calculations, condition lookup, and 38 CFR authority search
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Average 4.7/5 across 10 of 10 tools scored. Lowest: 4.1/5.
Each tool targets a distinct task: rating gap analysis, combined rating calculation, rolling window for a specific condition, presumptive eligibility, criteria comparison, retroactive pay, secondary conditions, compensation rates, CP exam prep, and legal research. Even similar tools like analyze_rating_gap and compare_rating_criteria differ in input (condition+percentage vs. diagnostic code) and output (gap analysis vs. full criteria table).
All tool names follow the same verb_noun pattern with snake_case and lowercase, using clear action verbs (analyze, calculate, check, compare, compute, find, lookup, prepare, search). There are no mixed conventions or inconsistent naming styles.
10 tools is a well-scoped number for a veterans' benefits server. The set covers rating analysis, calculations, research, and exam preparation without redundancy or bloat. It is neither too thin nor excessively large.
The toolset covers the core domain comprehensively: rating criteria, combined ratings, compensation rates, retroactive pay, presumptive conditions, secondary conditions, and CP exam prep. Minor gaps include lack of tools for claim filing or appeal processes, but these are outside the stated scope (informational/analytical only).
analyze_rating_gapAnalyze a rating gapAUse 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. It describes what the criteria require; only VA decides a rating.
| Name | Required | Description | Default |
|---|---|---|---|
| conditionName | Yes | Condition to analyze (e.g., "PTSD", "Lumbar strain"). | |
| currentPercent | Yes | Current VA rating percentage for this condition (e.g., 30, 50, 70). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, openWorldHint=false, idempotentHint=true, destructiveHint=false, which covers safety and side-effect profile. The description adds context beyond annotations by explaining the return content (tiers and criteria), handling of edge cases (highest tier, no criteria), and clarifying that it only describes criteria, not decides ratings. It does not contradict annotations; in fact, the read-only claim aligns. The description does not mention any side effects or required permissions, but with readOnlyHint and idempotentHint, the safety profile is clear. A minor deduction for not explicitly stating that it returns a limited set of tiers (only higher tiers) but that is covered in purpose. So 4 is appropriate as it adds useful context without full behavioral detail.
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?
The description is concise, about 5 sentences, and front-loaded with the primary use case ('Use this when...'). Every sentence adds value: it explains the inputs, the output (tiers and criteria), edge cases, and a disclaimer about VA decision. No wasted words.
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?
Given the moderate complexity (2 params, no enums, no output schema), the description is complete. It explains the output structure (current tier, next tier, all higher tiers), handles edge cases (highest tier, no criteria), and clarifies limitations (does not decide rating). With readOnlyHint and idempotentHint, the safety profile is clear. The only missing piece is explicit return format (e.g., JSON structure), but since there is no output schema, the description provides a functional overview that should suffice for an agent to anticipate the response. No further detail is necessary.
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%, meaning both parameters (conditionName, currentPercent) are described in the schema. The description adds examples for each ('e.g., "PTSD"', 'e.g., 30, 50, 70') and clarifies that currentPercent is the current rating percentage. It also implicitly explains the role of conditionName as the condition to analyze. Since coverage is high, baseline is 3, but the description adds just enough detail (examples and context) to earn a 4. It doesn't provide format constraints beyond schema, but the examples help.
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?
The description uses a specific verb ('Use this when a veteran gives a condition name and the percentage') and clearly identifies the resource (VASRD criteria) and the action (compare percentage against criteria). It distinguishes from siblings by focusing on the gap analysis between current percentage and higher tiers, and explicitly mentions reporting when at highest tier or no criteria on file, which differentiates from 'compare_rating_criteria' likely doing a direct criteria comparison.
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?
Explicitly states when to use ('Use this when a veteran gives a condition name and the percentage currently assigned...'). It implies when not to use by mentioning alternatives like 'compare_rating_criteria' for direct criteria comparison, and also describes edge cases (already at highest tier, no criteria on file) that guide usage. It clarifies that the tool only describes criteria and does not decide ratings, which guides expectations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
calculate_combined_ratingCalculate combined VA ratingAUse this when a veteran has two or more VA disability rating percentages and wants the combined rating. Applies the 38 CFR 4.25 Combined Ratings Table procedure: pairwise combination in severity order, whole-percent rounding after each step, then conversion to the nearest 10. Returns the combined percentage before and after that conversion, plus the arithmetic for each step. The result differs from adding the percentages and from a simple product. It reports what 38 CFR 4.25 yields for the percentages supplied, not what VA has assigned, and it does not evaluate special monthly compensation.
| Name | Required | Description | Default |
|---|---|---|---|
| ratings | Yes | Array of individual disability rating percentages (0–100), e.g., [70, 50]. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description reveals the internal calculation procedure (pairwise combination in severity order, whole-percent rounding after each step, then conversion to nearest 10) and states what the tool returns (combined percentage before/after, arithmetic for each step). It also clarifies that it does not evaluate SMC. Annotations already declare readOnlyHint and destructiveHint false, so the description adds meaningful behavioral detail beyond structured data.
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?
The description is efficiently written, opening with the trigger condition and then packing essential procedural details, output expectations, and limitations into a few sentences. Every sentence adds distinct value—usage trigger, algorithm, return values, and scope exclusions. It avoids redundancy and is well-structured for quick comprehension.
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?
Given the tool's simplicity (one parameter, no output schema), the description is exceptionally complete. It explains both the inputs (ratings array) and outputs (combined percentage before/after conversion, arithmetic per step), states the governing rule (38 CFR 4.25), and explicitly bounds its scope (not what VA assigned, no SMC). There are no missing behavioral or usage aspects needed for correct invocation.
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?
The schema documents the single parameter 'ratings' as an array of numbers (0–100) with an example. The description adds contextual meaning by specifying the requirement of 'two or more' ratings and describing the severity-order pairwise combination, which implies ordering semantics not present in the schema. Thus it enhances parameter understanding beyond the schema baseline.
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?
The description clearly states the tool's purpose: 'Use this when a veteran has two or more VA disability rating percentages and wants the combined rating.' It identifies the specific verb (calculate), resource (combined rating), and scope (two or more ratings). It also distinguishes from naive addition and product, and names the governing regulation (38 CFR 4.25), helping an agent differentiate it from sibling tools.
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 description explicitly tells when to use the tool: 'Use this when a veteran has two or more VA disability rating percentages.' It also provides exclusions: 'does not evaluate special monthly compensation' and 'reports what 38 CFR 4.25 yields... not what VA has assigned,' clarifying what not to use it for. This goes beyond mere implication and guides proper tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
calculate_rolling_windowCheck a 12-month absence windowAUse this when a veteran supplies dates of incapacitating episodes and the question involves the 38 CFR 4.71a formula for rating intervertebral disc syndrome on incapacitating episodes, diagnostic code 5243. Totals the calendar duration of those episodes inside the 12-month window ending on a reference date. That formula bands on total calendar duration in weeks, so weekend and holiday days inside an episode count, and only periods flagged as bed rest prescribed by a physician count toward a tier. Returns the window, a per-period breakdown, the tier the flagged episodes would support, and a separate employer-leave workday count that plays no part in that tier. The tier it reports is an estimate from the episodes supplied. It does not decide FMLA entitlement and does not apply to conditions rated outside diagnostic code 5243.
| Name | Required | Description | Default |
|---|---|---|---|
| referenceDate | No | The reference date for the 12-month rolling window (YYYY-MM-DD). Defaults to today. Typically the anticipated C&P exam date. Must be a real calendar date; an unparseable value is rejected. | |
| absencePeriods | Yes | Array of absence periods. Each must have at least a startDate. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the operation as read-only, idempotent, and non-destructive. The description goes beyond these by explaining the calculation uses calendar duration, weekends/holidays count, only physician-prescribed bed rest contributes to the tier, and the result is an estimate rather than a guarantee. It also explicitly says the employer-leave workday count does not affect the tier.
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?
The description is a single dense paragraph but every sentence is substantive and contributes either to scope, calculation mechanics, return contents, or exclusions. It is longer than average but not padded, and the most important usage guidance is front-loaded in the first sentence.
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?
Given the tool's specialized medical formula context, it has no output schema, and all 2 parameters are fully documented, the description fully fills the missing gaps: what is returned, what counts toward the tier, the estimate nature, and its limitations. It is complete enough for the agent to invoke correctly and interpret outcome without extra assumption.
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?
The input schema covers 100% of the parameters with detailed descriptions, so the baseline is high. The description adds useful semantic context around how absence periods are treated—calendar days count and physician-prescribed bed rest is a gate for tier contribution—without repeating the full schema. It does not fully describe reference date defaults or reversal rules, but those are thoroughly covered in the schema.
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?
The description clearly identifies the tool's purpose as totaling incapacitating episodes within a 12-month window under the specific 38 CFR 4.71a formula for diagnostic code 5243. It distinguishes the tool from siblings by naming the exact regulatory formula and explicitly stating what it does not do (e.g., no FMLA decision, not for other codes).
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 opening line spells out the exact trigger: 'Use this when a veteran supplies dates of incapacitating episodes and the question involves the 38 CFR 4.71a formula.' It also provides exclusions: not for FMLA entitlement and not for conditions outside diagnostic code 5243, giving clear when/not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
check_presumptive_eligibilityCheck presumptive eligibilityAUse this when a veteran asks whether a condition is presumptively service connected, or which conditions are presumptive for a given exposure or service era. Returns matching presumptive conditions with the service era, exposure type, required service, legal authority and evidence needed for each. At least one of condition, serviceEra or exposureType is required. Filters combine with AND: condition plus exposureType or serviceEra narrows to their intersection, and each filter needs at least one word of three or more characters or the query is refused. An empty result means no entry satisfies that exact combination, not that the condition is non-presumptive. Whether a particular veteran meets the service requirement depends on service records this tool does not read.
| Name | Required | Description | Default |
|---|---|---|---|
| condition | No | Condition to check for presumptive status (e.g., "Parkinson's disease", "Hypertension"). | |
| serviceEra | No | Service era or conflict (e.g., "Vietnam", "Gulf War", "Post-9/11") for era-specific presumptives. | |
| exposureType | No | Known toxic/environmental exposure (e.g., "Agent Orange", "burn pits", "Camp Lejeune water"). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, but the description adds substantial context: it lists the returned fields, explains the AND combination logic, warns that an empty result does not mean non-presumptive, and notes the tool does not read service records. These behaviors go well beyond the annotations and are critical for correct interpretation.
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?
The description is front-loaded with the primary use case, then efficiently covers return value, filter rules, empty-result interpretation, and limitations. Every sentence carries necessary information, and the logical flow is clear without being verbose.
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?
With no output schema, the description fully explains what is returned. It also covers edge cases (empty result), required inputs despite schema saying optional, and the tool's scope (does not read service records). For a tool with only three parameters and no output schema, this description is complete and leaves no ambiguity.
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?
Although schema coverage is 100% for the three parameters, the description adds crucial semantics not present in the schema: it states that at least one parameter is required (the schema says required: []), that filters combine via AND, and that each filter must contain a word of three or more characters. This directly compensates for a potentially misleading schema and helps the agent avoid failed queries.
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?
The description opens with a specific verb and resource: 'Use this when a veteran asks whether a condition is presumptively service connected, or which conditions are presumptive for a given exposure or service era.' This clearly distinguishes it from sibling tools like calculate_combined_rating or search_legal_authority, which handle other aspects of the rating process.
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?
It explicitly states when to use ('Use this when...') and clarifies the types of queries it answers. It does not name alternative sibling tools or state when not to use it, but the unique purpose is clear enough that a 4 is warranted rather than a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
compare_rating_criteriaCompare rating criteriaAUse 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.
| Name | Required | Description | Default |
|---|---|---|---|
| diagnosticCode | Yes | VA diagnostic code (e.g., "8100" for migraines, "5260" for knee). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds significant behavioral detail beyond the annotations: it returns criteria at every tier sorted by percentage, includes condition name/body system/38 CFR reference, returns an empty result for unknown codes, and explicitly takes a diagnostic code rather than a condition name. This goes well beyond the readOnly and idempotent hints.
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?
The description is concise, two sentences, and front-loaded with the usage trigger. Every sentence earns its place, covering purpose, input format, output contents, exception behavior, and exclusions without redundancy.
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 read-only tool with no output schema, the description fully covers what the tool returns (tiers, condition details, CFR reference), how it behaves for missing codes, and how it differs from sibling tools. No gaps remain.
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?
Although the schema already documents the diagnosticCode parameter with examples, the description adds crucial semantic context: it distinguishes diagnostic code from condition name, clarifies that unknown codes yield an empty result, and explains the purpose of the parameter in the tool's logic.
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?
The description clearly states the tool returns VASRD rating criteria for a given VA diagnostic code, with a specific verb ('Returns') and resource ('VASRD criteria'). It also distinguishes itself from related tools by noting it is not a rating lookup and does not combine ratings.
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 opening sentence explicitly states when to use the tool ('when a veteran names a VA diagnostic code and wants the rating criteria for it'). It also clarifies exclusions: not for rating pay lookup and not for combining ratings, which differentiates it from siblings like lookup_compensation_rate and calculate_combined_rating.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
compute_retroactive_payEstimate retroactive back payAUse this when a veteran gives an effective date and a rating increase and asks what the retroactive amount would be. Returns an estimate of the difference in monthly compensation for each month of the period, with a per-month breakdown, the assumptions behind it, and its own disclaimer. Under 38 CFR 3.31 payment starts on the first of the month following the effective date, or in that same month when the effective date is the first, and the period runs through the month of adjudication. Monthly rates for past years are reconstructed from current published rates back-adjusted by the SSA cost-of-living chain, which makes the total an estimate rather than a table lookup. It handles an increase only: the new rating has to be higher than the previous one, and effective dates before 1990 are refused. It does not set an effective date and it does not report an amount VA has authorized.
| Name | Required | Description | Default |
|---|---|---|---|
| isTdiu | No | Whether the new rating includes TDIU (treats as 100% for $). | |
| toRating | Yes | New VA rating percentage (0-100). | |
| hasSpouse | Yes | Whether the veteran was married during the period. | |
| fromRating | Yes | Previous VA rating percentage (0-100). | |
| effectiveDate | Yes | ISO date YYYY-MM-DD of rating change effective date. | |
| dependentCount | Yes | Number of dependent children under 18. | |
| adjudicationDate | No | ISO date the rating decision was issued. Defaults to today. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only, idempotent, non-destructive. Description adds methodology (back-adjusted rates via SSA COLA), legal basis (38 CFR 3.31), and limitations (estimate, not table lookup). No contradictions.
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?
Single paragraph densely packed with essential information, front-loaded with usage trigger. Every sentence is informative and necessary; no fluff or redundancy.
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?
Despite no output schema, description describes return content (per-month breakdown, assumptions, disclaimer) and covers all relevant behavioral aspects: constraints, methodology, and what it does not do. Highly complete for a complex tool.
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 has 100% coverage, but description adds significant meaning: explains how effective date interacts with legal rule, how isTdiu affects 100% treatment, and the reconstruction of historical rates from current rates. Goes beyond simple parameter descriptions.
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?
The description clearly states the tool estimates retroactive pay for a veteran given an effective date and rating increase. It distinguishes from siblings by focusing on retroactive calculation rather than current rate lookup or eligibility checks.
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?
Explicitly says 'Use this when...' and lists constraints: only increases, effective dates before 1990 refused, and clarifies it does not set effective dates or report VA-authorized amounts. Provides clear when-to-use and when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
find_secondary_conditionsFind secondary conditionsAUse this when a veteran names a service-connected condition and asks what other conditions can follow from it. Returns conditions on file as medically linked to that primary condition, each with the strength of the supporting evidence, the medical rationale, key studies, filing notes and the diagnostic codes involved. An empty result means nothing is on file for that search term, not that no link exists. It does not diagnose, it does not establish that a particular veteran's condition is secondary, and it does not supply the medical nexus opinion a secondary claim needs.
| Name | Required | Description | Default |
|---|---|---|---|
| primaryCondition | Yes | Primary service-connected condition to search against (e.g., "PTSD", "Lumbar strain"). Partial matches supported. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, etc., but the description adds substantial context: it details the output structure (strength of evidence, medical rationale, studies, filing notes, diagnostic codes), explains empty-result semantics, and warns about limitations. This goes well beyond the annotations.
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?
The description is four sentences, front-loaded with usage, and each sentence serves a distinct purpose (when to use, what it returns, empty-result caveat, limitations). No wasted words.
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?
With no output schema, the description adequately covers return content ('conditions on file... each with the strength of the supporting evidence, medical rationale, key studies, filing notes and diagnostic codes') and empty-result behavior. It also addresses boundary conditions (no diagnosis, no nexus opinion), making the description complete for such a simple tool.
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% and the schema already describes the parameter and partial-match behavior. The description only implies the parameter's meaning by referencing 'primary condition' but adds no additional syntax or format details. Baseline 3 applies; no extra value beyond schema.
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?
The description clearly states the verb 'find' and the resource 'secondary conditions' with specific context: 'when a veteran names a service-connected condition and asks what other conditions can follow from it.' This differentiates from siblings like calculate_combined_rating or analyze_rating_gap, which serve distinct purposes.
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?
It explicitly states when to use the tool ('Use this when a veteran names...') and provides strong when-not guidance by listing what it does not do ('does not diagnose, does not establish...', 'does not supply the medical nexus opinion'). It stops short of naming alternative tools, so not a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
lookup_compensation_rateLook up monthly compensation rateAUse this when a veteran wants the monthly VA disability compensation amount for a given rating percentage and dependent situation. Returns the monthly and annual amounts from the VA compensation rate table in effect, with the rate year and effective date. The rating is read to the nearest 10 percent, and dependents change the amount only at 30 percent and above. Children are counted as children under 18; school-age children 18 to 23, dependent parents and aid and attendance are outside what it models. It gives the published rate for that combination, not what a specific veteran is paid, and it is not a back-pay calculation for a past period.
| Name | Required | Description | Default |
|---|---|---|---|
| rating | Yes | Disability rating percentage (0–100, rounded to nearest 10). | |
| hasSpouse | No | Whether veteran has a spouse. Affects rates at 30%+. Defaults to false. | |
| childrenCount | No | Dependent children under 18. Affects rates at 30%+. Defaults to 0. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (readOnly, idempotent, non-destructive), the description discloses rounding behavior ('rating is read to the nearest 10 percent'), the threshold for dependents ('only at 30 percent and above'), and specific limitations on dependents modeled. It also clarifies that it returns the published rate, not an individual's actual payment, adding context about the data source.
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?
The description is front-loaded with the primary use case and output, then provides necessary rounding and scope limitations, followed by exclusions. At four sentences, it remains concise and every sentence adds distinct information, though it could be slightly tightened without losing content.
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?
The description covers the output format (monthly and annual amounts, rate year, effective date), key behavioral rules (rounding, dependency thresholds), and explicitly states what it does not do (not actual pay, not back-pay). Given there is no output schema, this sufficiently explains the tool's behavior and covers the main context needed for correct use.
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?
The schema provides 100% coverage, already describing that rating is rounded to the nearest 10 and that spouse/children affect rates at 30%+. The description mostly restates these schema details without adding new semantic meaning for the parameters, so it merits the baseline 3.
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?
The description opens with a clear use case ('Use this when a veteran wants the monthly VA disability compensation amount for a given rating percentage and dependent situation') and specifies the exact output (monthly and annual amounts, rate year, effective date). It distinguishes itself from siblings by explicitly excluding back-pay calculations, which aligns with compute_retroactive_pay.
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?
It explicitly states when to use the tool ('Use this when...') and provides exclusions: it is not for a specific veteran's actual pay and not for back-pay calculations. It also clarifies that certain dependent situations (school-age children 18-23, dependent parents, aid and attendance) are outside the model, guiding users away from using it for those scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
prepare_cp_examPrepare for a C&P examAUse 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.
| 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. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds value by explaining the tool is an 'Educational reference' and explicitly that it does not schedule/contact VA, nor does it influence the rating ('examiner's findings and VA decide the rating'). This provides useful non-obvious context beyond the structured annotations.
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?
The description is three sentences, each earning its place. It opens with a clear trigger, lists deliverables in a compact list-like form, ends with exclusions and expected outcome. No filler or redundancy; every sentence provides decision-relevant 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?
With no output schema, the description fully explains the richness of the return: exam type, length, examiner actions, common questions, DBQ sections, records, misconceptions, rating tiers, and functional prompts. It also handles edge cases (general exam guide) and clearly delimits the tool's bounds (not scheduling).
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?
The input schema gives 100% coverage for both parameters: 'condition' with examples and 'currentRating' with context. The description adds minimal additional parameter meaning, only noting that a guide exists for some conditions but not others. Since the schema already carries the burden, a baseline 3 is appropriate.
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?
The description clearly states the tool's purpose: 'Use this when a veteran has a VA compensation and pension examination scheduled for a condition.' It enumerates specific deliverables (exam type, length, questions, DBQ sections, records, rating tiers) and differentiates itself from siblings by focusing on exam preparation as a reference, not rating calculation or legal lookup.
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?
Explicitly specifies the trigger condition: when a veteran has a scheduled C&P exam and wants to understand its process. It also states exclusions ('does not schedule, reschedule or contact VA') and clarifies outcomes, making it clear when to use this tool versus other support tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_legal_authoritySearch case law and regulationsAUse this when a question calls for the text of a VA rating regulation or for case law, searched by keyword or diagnostic code. Returns 38 CFR rating criteria for matching conditions, excerpts from Court of Appeals for Veterans Claims decisions with docket number, case name and relevance score, and the statutory standards for benefit of the doubt, duty to assist, and reasons and bases. CAVC decisions are binding precedent for the Board of Veterans' Appeals. The limit parameter caps results per source, default 5 and maximum 10. Docket numbers and case names come only from the returned results, and when the case-law corpus is empty the response says so and returns regulatory results alone. It does not read an individual claim and it is not legal advice.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max results (default 5, max 10). | |
| query | Yes | Search query (e.g., "PTSD secondary to MST", "DC 8100 migraine 50 percent criteria", "CUE in combined rating calculation"). | |
| diagnosticCode | No | Filter by diagnostic code (e.g., "8100"). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is clear. The description adds behavioral context: it explains the limit parameter behavior, that docket numbers come only from results, and how it handles an empty case-law corpus. This goes beyond annotations and gives useful understanding of how the tool behaves.
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?
The description is a single dense paragraph but every sentence provides distinct information: what it searches, what it returns, binding authority, parameters, behavior on empty corpus, exclusions. It is front-loaded with the main purpose and usage, and does not waste words. Very concise for the amount of detail.
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?
Given that there are 3 params, 100% schema coverage, and annotations cover safety, the description covers all essential aspects: sources, return types, limitations, and exclusions. It also clarifies legal status (binding precedent) and performance (default cap). With no output schema, the description explains return content adequately. Complete for the tool's complexity.
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?
The schema has 100% coverage, with each parameter described with examples (query example includes real search strings, limit description includes default/max, diagnosticCode example). The description adds value by explaining how the limit works and how the query relates to results, but mostly reinforces the schema. Since schema already provides examples, the description adds marginal value but doesn't provide new information not in schema.
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?
The description clearly states it searches for VA rating regulations and case law, with specific details about sources (38 CFR, CAVC decisions). It distinguishes from siblings by mentioning keyword or diagnostic code search and returning specific content types. However, it shares similarity with 'compare_rating_criteria' which might also search regulations, but the focus on case law and legal standards sets it apart.
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 description explicitly says 'Use this when a question calls for the text of a VA rating regulation or for case law', giving clear context. It also mentions what it does not do ('does not read an individual claim and is not legal advice'), but does not name specific sibling alternatives. It provides enough guidance for when to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
No comments yet. Be the first to start the discussion!
