VA facility locations, services, wait times, and satisfaction scores
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.4/5 across 3 of 3 tools scored.
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.
find_va_facilitiesAInspectFind 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_facility_detailAInspectGet 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_facility_servicesAInspectGet 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.
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!
