VA facility locations, services, wait times, and satisfaction scores
Find VA (Department of Veterans Affairs) facilities by location.
Search for VA medical centers, clinics, benefits offices, cemeteries,
and vet centers. At least one location parameter should be provided.
Args:
state: Two-letter state abbreviation (e.g., "CA", "TX").
city: City name to search in.
zip_code: 5-digit ZIP code to search near.
facility_type: Type of facility — "health" (medical centers/clinics),
"benefits" (regional benefits offices), "cemetery" (national
cemeteries), or "vet_center" (readjustment counseling). Default "health".
limit: Maximum number of results (default 25, max 200).
| Name | Required | Description | Default |
|---|---|---|---|
| city | No | ||
| limit | No | ||
| state | No | ||
| zip_code | No | ||
| facility_type | No | health |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It provides some behavioral constraints like 'At least one location parameter should be provided', the default facility_type, and limit default/max, but it does not disclose response behavior (e.g., sorting, pagination, error conditions) or any side effects. This is a partial disclosure, not comprehensive.
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 a clear one-sentence summary, followed by a helpful expansion of facility types and parameter constraints. The Args list is concise, well-organized, and every sentence adds value 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?
The tool has an output schema, so return values are presumably covered there. The description explains all 5 parameters and important constraints like the location requirement and limit. It omits details on error handling or authentication, but for a search tool this is not a major gap. Overall, it is fairly complete.
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 has only titles (0% description coverage), so the description is the sole source of parameter meaning. It explains state as a two-letter abbreviation, zip as 5-digit, facility_type with enumerated values and their meanings, and limit with default and max. This exceeds the schema and fully compensates for the lack of 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 starts with 'Find VA (Department of Veterans Affairs) facilities by location', which is a specific verb+resource+scope statement. It further enumerates facility types (medical centers, clinics, benefits offices, cemeteries, vet centers) and clearly distinguishes this from sibling tools that focus on facility details or services.
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 implies usage through 'Search for VA medical centers...' and notes 'At least one location parameter should be provided'. However, it does not explicitly mention when to use this tool over alternatives (e.g., get_facility_detail) or provide any exclusion criteria, so guidance is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get detailed information for a specific VA facility.
Returns comprehensive facility data including address, contact info,
operating hours, services offered, patient wait times, and patient
satisfaction scores.
Args:
facility_id: The VA facility ID (e.g., "vha_648", "vba_310",
"nca_907"). Obtain from find_va_facilities results.
| Name | Required | Description | Default |
|---|---|---|---|
| facility_id | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden of disclosure. It describes the comprehensive return data and implies a read-only operation. It does not mention error handling or permissions, but for a GET-style tool this is acceptable.
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 well-structured: a clear first sentence for purpose, a brief summary of response content, and an Args section. Every sentence contributes value without unnecessary verbosity.
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 tool with an output schema, the description covers the input source, what the output contains, and the workflow. It is self-sufficient and complete for an agent to invoke correctly.
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 offers no description (0% coverage), but the description compensates with a detailed Args section including example IDs (vha_648, vba_310, nca_907) and guidance to obtain the ID from find_va_facilities results. This fully defines the parameter semantics.
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 'Get detailed information for a specific VA facility' with a specific verb and resource. It lists concrete response categories (address, contact info, etc.), distinguishing it from sibling tools that find facilities or focus on services.
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?
Provides explicit guidance to obtain the facility_id from find_va_facilities results, establishing the correct workflow. Does not mention when to avoid this tool or compare it to get_facility_services, so no exclusions are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the list of services offered at a specific VA facility.
Returns all healthcare and administrative services available at the
facility, including specialty care, mental health, dental, pharmacy,
and other clinical services.
Args:
facility_id: The VA facility ID (e.g., "vha_648"). Obtain from
find_va_facilities results.
| Name | Required | Description | Default |
|---|---|---|---|
| facility_id | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It describes the return as 'all healthcare and administrative services' and gives examples, which adds useful context. It does not explicitly state that it is a read-only operation or address potential errors, but the tool name and verb imply a safe read.
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 and well-structured: a one-line purpose, a brief return explanation, and a clean Args section. Each sentence adds relevant information without redundancy or fluff.
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 tool with a single parameter and an output schema, the description adequately communicates what the tool does and what to expect. It provides example service categories and instructs how to obtain the required ID. Edge cases like invalid IDs are not covered but are not essential for this simple retrieval 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?
The schema provides no description for facility_id, so the description's explanation that it is a VA facility ID with an example ('vha_648') and source instruction from find_va_facilities fully compensates. This adds significant meaning beyond the bare schema type.
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 'get_facility_services' retrieves the list of services for a specific VA facility, using a specific verb and resource. It distinguishes itself from sibling tools like find_va_facilities and get_facility_detail by focusing explicitly on services.
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 provides clear context for when to use the tool (when you have a facility and need its services) and instructs on obtaining the facility_id from find_va_facilities. However, it does not explicitly mention when not to use it or compare it with get_facility_detail, so it lacks an explicit exclusion statement.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claiming proves that you control a remote MCP connector. It does not move, proxy, or interrupt the server.
Open the connector listing, choose Claim ownership, and sign in to Glama.
Complete one verification method:
GitHub identity — fastest for official registry listings. For a namespace such as io.github.alice/server, link the matching GitHub user or an account that owns the GitHub organization, then choose Claim with GitHub.
HTTP challenge — works when you can deploy a public file. Generate a token, publish the exact JSON Glama shows at /.well-known/glama.json on the same origin as the connector, then choose Check HTTP challenge.
DNS challenge — works when you control DNS but cannot change the server. Generate a token, create the exact TXT record Glama shows, wait for it to propagate, then choose Check DNS challenge.
After verification, Glama sends a confirmation email and gives you access to listing details, thumbnails, health checks, and analytics. Keep the HTTP file or DNS record in place: Glama periodically checks it and ownership remains verified while the token is discoverable.
The HTTP ownership file has this structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"claim": "glama_claim_..."
}Claim tokens are opaque, stable, and bound to the signed-in Glama account. They contain no email address or other personal information. If Glama can no longer discover a verified HTTP or DNS token, it starts a seven-day grace period before removing claim-based access. Restore the same token during that period to keep ownership verified. Never publish an email address, Glama session token, GitHub token, or connector credential as ownership proof.
If verification fails, confirm that you copied the current token exactly. The HTTP file must be public, return valid JSON with a successful HTTP response, and stay on the connector's origin. DNS changes may need more time to propagate. A claim cannot transfer to a different origin or hostname: if the connector target changes, Glama starts the grace period and the new target must be claimed separately after the previous claim is released.
For a connector linked to the official MCP Registry, registry updates continue to replace its name, description, and URL by default. After claiming, open Manage connector and enable Use Glama listing details as the source of truth if edits made on Glama should be preserved. Categories and thumbnails are always managed on Glama; registry linkage and technical connection settings continue to sync.
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
To improve your MCP server's ranking:
Claim ownership of the server listing
Complete the server profile with an accurate description and thumbnail
Provide a test profile so Glama can connect to and evaluate the server
Keep tool definitions clear and complete to earn a high Tool Definition Quality Score (TDQS)
Route real usage through the Glama Gateway; more recorded successful server uses also improve the ranking
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!
CMS quality ratings, payer-negotiated prices, and clinician data for 41K+ US healthcare facilities.
Health professional shortage areas and community health centers
900,000+ Board of Veterans' Appeals decisions: VA outcomes, grant rates, PACT Act, ratings.
Medicare spending, chronic conditions, hospital quality, readmissions, and enrollment
Add one secure layer between your agents and this server.
Each tool has a clearly distinct purpose: finding facilities, getting detailed info, and listing services. Even though get_facility_detail includes services, the tools are not confusing because one is comprehensive and the other is specific.
All tools use a verb_noun pattern, but there is a minor inconsistency: 'find_va_facilities' uses plural 'facilities' while the other two use singular 'facility'. The verbs 'find' and 'get' are both clear, so the pattern is mostly consistent.
Three tools is on the low end but appropriate for this focused read-only server. Each tool fills a necessary role—search, detail, and services—without unnecessary bloat.
The server covers the core read-only workflow: find facilities, view details, and check services. Minor gaps exist, such as no search by service type or listing all facilities without a location parameter, but these are not critical for the domain.
