list_my_va_casesList the veteran's OWN VA cases (read-only). Requires the veteran's personal VetAid agent key in the request's Authorization header (Bearer vak_...). Returns each case's id, status, timestamps, and its rated / denied / claimed conditions. Only ever returns the key owner's data.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Changes observed during successful MCP inspections. Dates show when Glama detected each change.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior. The description adds meaningful behavior beyond annotations: the required Bearer auth format, the guarantee that only the owner's data is returned, and the specific returned fields.
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 dense sentences with no wasted words. The read-only designation and auth requirement are front-loaded, and the return contents are summarized efficiently.
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 zero-parameter read-only list tool, this is complete: it specifies auth, data scoping, and return fields. There is no output schema, but the description supplies the essential return information an agent needs to evaluate the result.
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 tool has zero parameters, so there is no parameter burden for the description to carry. The auth header requirement is the only input concern, and it is clearly documented.
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 the specific verb 'List', the resource 'veteran's OWN VA cases', and the read-only nature. The emphasis on 'OWN' and key-owner data distinguishes it from sibling tools that analyze or modify cases.
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?
Clear context is provided: use requires the veteran's personal agent key in the Authorization header and only returns the key owner's data. It does not explicitly name sibling alternatives or when not to use the tool, but the intended use is unmistakable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
Most tools have clear individual roles, and the personal workflow tools are unambiguous. However, va_condition_intelligence overlaps with va_denial_stats, va_evidence_that_wins, and va_top_authorities, since it also reports outcome shares, evidence associations, and cited authorities, so selecting the right tool often depends on carefully reading the long descriptions.
All names use lower_snake_case and are readable, with a consistent verb-first pattern for personal tools (get_my_*, list_my_*, run_my_*) and a va_ prefix for public data tools. The mix of verb-first and noun-phrase names is a minor inconsistency, but the two families are predictable and internally consistent.
Nine tools is a well-scoped count for this domain. Each tool maps to a meaningful operation: four cover the personal case-analysis workflow and five cover aggregate VA data intelligence, with no obvious bloat at the tool-count level.
The surface covers the core lifecycle: list cases, check credits, run an analysis, retrieve the analysis summary, and query the main public intelligence areas (outcomes, evidence, authorities, and manual changes). Minor gaps exist, such as no explicit analysis-status endpoint for the 5-8 minute run and no separate condition-level denial-reason tool, but agents can work around these.