CMS quality ratings, payer-negotiated prices, and clinician data for 41K+ US healthcare facilities.
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.1/5 across 5 of 5 tools scored.
Each tool serves a clearly distinct purpose: search discovers facilities, get_facility provides metadata and tool compatibility, get_facility_profile returns detailed profiles, and the two hospital-specific tools cover clinicians and pricing. There is no meaningful overlap between these five operations.
All tool names follow a consistent verb_noun pattern: get_facility, get_facility_profile, get_hospital_clinicians, get_hospital_prices, and search_facilities. The naming is uniform and predictable.
With five tools, the server is well-scoped for its purpose of facility lookup and hospital-specific data retrieval. Each tool covers a distinct aspect without redundancy or bloat.
The set covers search, lookup, profiles, and specialized hospital data (clinicians and prices), providing a complete workflow for hospital facilities. Minor gaps exist for non-hospital facility types, which only have profile access and no specialized data tools, but this appears driven by data availability rather than an oversight.
get_facilityGet facility summary + capability URLsAInspectLook up one facility by {type, id}. Returns the index record plus canonical URLs and which detail tools work for it. Hospital ids are CMS CCNs.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Facility id (hospitals: 6-char CCN; systems: slug). | |
| type | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states what it returns (index record, canonical URLs, applicable detail tools) and adds a useful note about hospital IDs being CMS CCNs. However, it doesn't disclose error behavior, rate limits, or the read-only nature explicitly, which would be expected without 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?
Two sentences, front-loaded with the core action and parameters. The first sentence states what the tool does; the second explains the return value. No redundant words, every clause earns its place.
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?
Without an output schema, the description explains the return value clearly (index record, canonical URLs, which detail tools work). It also relates to sibling tools by mentioning 'detail tools.' It could mention error handling or caveats for certain types, but for a simple lookup tool, it's 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 schema already documents the id parameter (6-char CCN; slug) and type enum, with 50% coverage. The description repeats and reinforces the hospital ID note but doesn't meaningfully expand on parameter usage beyond what the schema provides. It fails to compensate for the undocumented type 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 uses a specific verb ('Look up one facility') and identifies the resource by type and id. It clearly distinguishes itself from siblings by noting it returns 'canonical URLs and which detail tools work for it,' which is unique.
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 clearly says when to use: when you have a specific type and id. It doesn't explicitly mention alternatives, but the note about 'which detail tools work' implies it serves as an entry point to detail tools. No exclusions are stated, so it loses a point.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_facility_profileGet full facility profile contentAInspectStructured summary for any facility; for hospitals the full profile markdown (quality measures, ratings context) is returned AS THE TEXT CONTENT BLOCK, with metadata (truncation flag, full URL) in structuredContent. max_chars bounds the markdown body.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | ||
| type | Yes | ||
| max_chars | No | Markdown budget (default 15000). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
It discloses that the full profile markdown is returned as the text content block and that metadata (truncation flag, full URL) appears in structuredContent. It also notes that max_chars bounds the markdown body, revealing truncation behavior; however, it does not address error responses or other operational details.
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 two sentences and front-loads the core purpose, with no filler. Every sentence contributes meaningful detail about return format and truncation control.
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 get-profile tool without an output schema, the description covers the return structure (text block vs structuredContent), truncation flag, full URL, and max_chars. It lacks explicit error-handling behavior and doesn't fully specify non-hospital outputs, but it is largely complete for typical usage.
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 only describes max_chars; the description adds that max_chars bounds the markdown body, enhancing its meaning. However, it does not explain id or type beyond the schema's enum, and with 33% coverage, the description only partially compensates.
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 a structured summary for any facility, with the full profile markdown for hospitals including quality measures and ratings context. This distinguishes it from siblings like get_facility or get_hospital_prices by specifying the complete profile content.
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 use for retrieving full facility profile content but does not explicitly mention alternatives or when not to use it. No exclusions are stated, and sibling differentiation is left to context rather than explicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_hospital_cliniciansGet hospital clinician rosterAInspectClinicians affiliated with a hospital (CMS data): name, specialty, Medicare procedure volumes, Open Payments totals. Available for ~4,570 hospitals (clinicians_tool_available flag). Filter matches name or specialty.
| Name | Required | Description | Default |
|---|---|---|---|
| ccn | Yes | Hospital CCN (6 characters). | |
| limit | No | Max clinicians (default 20). | |
| filter | No | Optional case-insensitive substring on name or specialty. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of behavioral disclosure. It reveals the data source (CMS), availability constraints, and filter semantics, but it does not specify that this is a read-only operation or describe any side effects, error handling, or response format. This adds some context but leaves significant behavioral aspects undocumented.
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 two sentences, concise and front-loaded. The first sentence states the core purpose and the second adds the availability flag and filter behavior. Every word contributes value, and it is appropriately sized for the tool's complexity.
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 retrieval tool with three parameters and no output schema, the description covers the main aspects: what data is returned, the data source, availability caveat, and filtering. It doesn't explain default limits or response structure, but those are partly covered by the schema. It is complete enough for most uses, with minor gaps.
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%, so the baseline is 3. The description adds minimal parameter-related detail beyond the schema: it reiterates the filter behavior already in the schema and doesn't clarify ccn or limit semantics beyond what's described. Thus, it provides modest additive value.
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 explicitly states the tool retrieves clinicians affiliated with a hospital, listing the data fields (name, specialty, Medicare procedure volumes, Open Payments totals). The title and name reinforce this, and the content clearly distinguishes it from sibling tools like get_facility or get_hospital_prices.
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 use context: it returns clinician data from CMS, available for ~4,570 hospitals with a flag. It also explains the filter behavior. However, it does not explicitly state when to avoid this tool or mention alternatives, so it stops short of a full 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_hospital_pricesGet payer-negotiated hospital pricesAInspectPayer-negotiated rates parsed from a hospital's federally required machine-readable file. Without drg: a per-DRG summary (payer count, min/median/max) across every DRG in the file. With drg (digits; zero-padded automatically): the individual payer-by-payer rates for that DRG. Available for ~2,060 hospitals (prices_tool_available flag).
| Name | Required | Description | Default |
|---|---|---|---|
| ccn | Yes | Hospital CCN (6 characters). | |
| drg | No | Optional MS-DRG code, e.g. "291" or "047". | |
| limit | No | Max DRG summary rows (default 100). Ignored when drg is given. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It explains the data source (federally required file), the dual output behavior (summary vs. payer-by-payer), automatic zero-padding for drg, and availability across ~2,060 hospitals. This goes beyond the schema and reveals important edge-case behavior, though it does not cover error handling or pagination if data is large.
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 delivering essential information without redundancy. It front-loads the core purpose and then details the two invocation modes. No word is wasted, and the structure logically flows from general to specific.
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 no output schema and no annotations, the description is quite complete: it covers the primary use cases, parameter semantics, and a key limitation (availability flag). It could specify the exact fields returned in the payer-by-payer output, but the current level is sufficient for an agent to select and invoke the tool 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?
Schema coverage is 100%, so the baseline is 3, but the description adds meaningful context: it explains how `drg` changes the output structure (summary vs. individual rates), notes automatic zero-padding, and clarifies the interaction with `limit` (ignored when drg is provided). This enriches the static schema 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's function: retrieving payer-negotiated hospital rates from machine-readable files. It distinguishes between two modes (summary vs. individual DRG rates), which immediately differentiates it from siblings like get_facility or search_facilities. The verb 'parsed' and resource 'payer-negotiated rates' are specific and unambiguous.
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 each mode (with/without drg) and mentions the availability flag, which implicitly guides when this tool is applicable. It does not explicitly exclude alternatives like get_facility_profile or search_facilities, but the focus on rate data makes the use case evident.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_facilitiesSearch US healthcare facilitiesAInspectSearch 41K+ US facilities (hospitals, nursing homes, home-health agencies, dialysis centers, health systems) by name and/or city, optionally filtered by state and type. Returns ids usable with the other tools plus capability flags.
| Name | Required | Description | Default |
|---|---|---|---|
| type | No | Facility type filter. | |
| limit | No | Max results (default 10). | |
| query | Yes | Name or city text to match (case-insensitive substring). | |
| state | No | Two-letter state/territory code filter, e.g. "CT". |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, but the description discloses that the tool searches a large dataset, returns identifiers, and includes capability flags. It also lists the entity types. It doesn't mention pagination or rate limits, but these are not critical for a search tool's core behavior.
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?
Two sentences that front-load the primary function and data scope, with zero filler. Every clause adds 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?
The tool is a simple search with no output schema; the description adequately conveys what it returns (ids and capability flags) and its role relative to sibling tools. No critical gaps.
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 covers all four parameters with detailed descriptions (e.g., query is case-insensitive substring, limit has min/max). The description adds a high-level summary ('by name and/or city, optionally filtered by state and type') but no new semantics beyond the schema, so baseline 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?
The description uses the specific verb 'Search', names the resource 'facilities', and scopes the dataset ('41K+ US facilities' with types). This distinguishes it from sibling get_* tools, which retrieve specific facility data.
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 states the tool is for searching by name/city with optional filters, and notes that it 'Returns ids usable with the other tools', implying the appropriate workflow. However, it doesn't explicitly mention when not to use it or name alternative search tools, so it lacks full exclusion guidance.
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!
