Hosted MCP server exposing US hospital procedure cost data to AI assistants
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.3/5 across 5 of 5 tools scored. Lowest: 2.9/5.
Each tool has a clearly distinct purpose: one retrieves a single cost, one lists code types, one lists codes within a type, one lists costs across hospitals for a code, and one lists hospitals. The overlap between get_hospital_chargemaster_cost and list_hospital_code_costs is explicitly clarified as complementary, not ambiguous.
All tools use lowercase snake_case with a verb-noun pattern: get_hospital_chargemaster_cost for single retrieval, list_codes/list_code_types/list_hospital_code_costs/list_hospitals for enumeration. The pattern is consistent and predictable.
Five tools is well-scoped for a medical pricing data API. Each tool serves a distinct discovery or retrieval function, and the count is appropriate for the domain—neither too sparse nor overloaded.
The tool surface covers the full read-only workflow: discover code systems (list_code_types), enumerate codes (list_codes), retrieve single costs (get_hospital_chargemaster_cost), compare across hospitals (list_hospital_code_costs), and access hospital metadata (list_hospitals). No obvious gaps for the stated purpose of querying hospital chargemaster data.
get_hospital_chargemaster_costGet hospital chargemaster costCLookup hospital chargemaster cost
| Name | Required | Description | Default |
|---|---|---|---|
| code | Yes | ||
| code_type | Yes | Code system the chargemaster/billing code belongs to, e.g. APR-DRG, CDM, CPT, HCPCS, MS-DRG, RC. Hospitals may also support additional proprietary code types not listed here. | |
| hospital_id | Yes | Opaque hospital identifier from list_hospitals. | |
| methodology | No | Pricing methodology. Omit to aggregate across all methodologies. | |
| revision_id | No | Optional. A revision_id from list_hospitals' per-hospital revisions array, to price that specific past revision instead of the hospital's latest one. Omit to use the latest revision. |
| Name | Required | Description |
|---|---|---|
| cost | No | |
| found | No | Whether a matching chargemaster cost record was found. |
| hospital | No | Hospital name returned by the MedPrice AI backend. |
| description | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds no behavioral context beyond what the readOnlyHint annotation already conveys. It does not mention aggregation behavior, revision handling, or any other operational details, so the description carries minimal weight in this dimension.
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, front-loaded sentence with zero wasted words. However, it is essentially a restatement of the tool name and does not add new information, so it earns a 4 rather than a 5.
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?
Even though an output schema exists, the description is extremely thin. It lacks any context about the tool's functionality, how to select it over alternatives, or what edge cases exist. For a tool with five parameters and sibling relationships, this is insufficient.
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 high (80%), so the schema already documents most parameters effectively. The description itself adds no parameter information, which keeps the score at 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 uses a specific verb ('Lookup') and clearly identifies the resource ('hospital chargemaster cost'). It does not explicitly distinguish from sibling tools like list_hospital_code_costs, so it falls short of a 5.
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?
No guidance is provided about when to use this tool versus the sibling tools list_hospital_code_costs or list_hospitals. The description offers no context or exclusions, leaving the agent to infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_codesList billing codes for a code typeAReturns every distinct code catalogued under a given code_type, paginated, with each code's raw chargemaster description and the number of hospitals reporting it. Use this to discover which codes exist under a code system (e.g. all CPT codes) before looking up prices with get_hospital_chargemaster_cost or list_hospital_code_costs.
| Name | Required | Description | Default |
|---|---|---|---|
| code_type | Yes | Code system to list codes for, e.g. "CPT". From list_code_types. | |
| page_size | No | Maximum number of results to return. Defaults to 500, capped at 500. | |
| page_token | No | Opaque token from a previous list_codes response. Omit for the first page. |
| Name | Required | Description |
|---|---|---|
| codes | No | |
| total_count | No | Total number of matching codes across all pages. |
| next_page_token | No | Opaque pagination token, empty when there are no more results. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds useful behavioral context beyond annotations: it returns every distinct code, is paginated, and includes raw chargemaster descriptions plus hospital counts. No contradictions found.
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, front-loaded with the core behavior, and then provides usage guidance. Every sentence earns its place with no filler 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?
Given the tool's moderate complexity, complete schema coverage, output schema presence, and strong annotations, the description is fully adequate. It covers purpose, usage context, pagination, and output contents without needing to restate return values already specified by the output schema.
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 schema already documents all three parameters thoroughly. The description adds only a general example ('all CPT codes') and workflow context, but does not materially enrich parameter semantics beyond what the schema provides.
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: 'Returns every distinct code catalogued under a given code_type, paginated...' It clearly distinguishes this tool from siblings by framing it as the code-discovery step before price lookups, and it names the downstream tools explicitly.
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 states when to use the tool: 'Use this to discover which codes exist under a code system... before looking up prices with get_hospital_chargemaster_cost or list_hospital_code_costs.' It names concrete alternatives and places this tool in the correct workflow.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_code_typesList billing code typesAReturns every distinct code_type (e.g. CPT, MS-DRG) with catalogued cost data, along with each type's distinct code count and total hospital reports. Unpaginated. Use this to discover which code systems have data before drilling into list_codes.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| code_types | No | One entry per distinct code_type present in the catalog, most code-rich first. Unpaginated. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds 'Unpaginated' and the fact that it returns aggregated counts and reports, which are not in the annotations. This adds meaningful behavioral context 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 two sentences: the first states exactly what is returned (with examples) and the second gives the intended usage scenario. No fluff, front-loaded with the most important 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?
For a zero-parameter tool with an output schema, the description adequately covers purpose, usage, and key behavioral notes (unpaginated). It also names the relevant sibling for further drilling, making it self-sufficient for an agent to decide when to invoke it.
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?
There are zero parameters, so the baseline per the rubric is 4. The description does not explain any parameters because there are none; the schema coverage is 100% (trivially) and no additional parameter semantics are needed.
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 every distinct code_type (e.g., CPT, MS-DRG) with associated cost data, code counts, and hospital reports. It distinguishes itself from the sibling tool list_codes by explicitly framing this as an aggregation-level listing.
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 when to use it ('Use this to discover which code systems have data') and points to the next step ('before drilling into list_codes'), which clearly differentiates it from the primary sibling. It also notes 'Unpaginated' as a usage caveat.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_hospital_code_costsList hospital costs for a billing codeAReturns cost stats for every hospital with a matching chargemaster entry for a code_type/code. Use this instead of calling get_hospital_chargemaster_cost once per hospital when comparing prices for the same procedure across hospitals (e.g. "which hospital has the cheapest MS-DRG 652?"). Defaults to returning every matching hospital (currently at most a few hundred) in one call. If the response's next_page_token is non-empty, the result set was truncated: call this tool again passing that exact value as page_token to get the next page, and keep doing so until next_page_token is empty - do not stop after one page and conclude a hospital has no data for this code. The response's total_count field (total across all pages) can be compared against how many results you've accumulated so far as a completeness check.
| Name | Required | Description | Default |
|---|---|---|---|
| code | Yes | ||
| code_type | Yes | Code system the chargemaster/billing code belongs to, e.g. APR-DRG, CDM, CPT, HCPCS, MS-DRG, RC. Hospitals may also support additional proprietary code types not listed here. | |
| page_size | No | Maximum number of results to return. Defaults to 500 (covering every matching hospital in one call at the current registry size), capped at 500. | |
| page_token | No | Opaque token from a previous list_hospital_code_costs response's next_page_token field. Omit for the first page. Do not pass any other value (e.g. an offset or cursor you construct yourself) here. | |
| methodology | No | Pricing methodology. Omit to aggregate across all methodologies. |
| Name | Required | Description |
|---|---|---|
| results | No | One entry per hospital with a matching chargemaster entry for this code (its latest revision only) - hospitals with no data for this code are omitted, not returned with found=false. |
| total_count | No | Total number of matching results across all pages, not just this page's results.length. Compare against results.length (plus any prior pages) to confirm you have the complete set before concluding a hospital or code has no data. |
| next_page_token | No | Opaque pagination token, empty when there are no more results. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true and destructiveHint=false, but the description goes further by disclosing pagination behavior, truncation semantics, and the meaning of next_page_token and total_count. This adds behavioral context beyond the structured annotations, such as the need to keep paging until next_page_token is empty.
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, front-loaded with the core purpose, and every sentence earns its place. It covers purpose, alternative usage, pagination, and completeness checking 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?
Given the output schema exists and the annotations are present, the description adds essential context about result-set size, pagination, and how to verify completeness. It is fully sufficient for an agent to correctly invoke the tool and interpret paginated results without confusion.
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 high at 80%, so the baseline is 3. The description adds meaningful semantics for page_token by explaining the exact usage ('call this tool again passing that exact value as page_token') and warns against constructing one's own cursor. It also clarifies that code_type/code map to chargemaster entries, reinforcing the schema's description.
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: 'Returns cost stats for every hospital with a matching chargemaster entry for a code_type/code.' It clearly distinguishes itself from the sibling get_hospital_chargemaster_cost by emphasizing the multi-hospital scope.
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: 'Use this instead of calling get_hospital_chargemaster_cost once per hospital when comparing prices for the same procedure across hospitals.' It also explains when to use pagination and warns against stopping after one page, giving clear when-to-use and when-to-keep-calling context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_hospitalsList supported hospitalsAReturns the hospitals supported by the medprice.ai API, with their hospital_id (opaque DB key), EIN, name, structured_locations (addresses with geocoded coordinates where available), last_updated_on, and revision history (with per-revision has_payer_data and revision_id). Defaults to returning the entire registry (currently a few hundred hospitals) in one call. If the response's next_page_token is non-empty, the result set was truncated: call this tool again passing that exact value as page_token to get the next page, and keep doing so until next_page_token is empty - do not stop after one page and conclude the list is complete. The response's total_count field (total across all pages) can be compared against how many hospitals you've accumulated so far as a completeness check, e.g. before answering questions like 'does medprice.ai cover any hospitals in Iowa'.
| Name | Required | Description | Default |
|---|---|---|---|
| page_size | No | Maximum number of hospitals to return. Defaults to 500 (covering the entire current registry in one call), capped at 500. | |
| page_token | No | Opaque token from a previous list_hospitals response's next_page_token field. Omit for the first page. Do not pass any other value (e.g. an offset or cursor you construct yourself) here. |
| Name | Required | Description |
|---|---|---|
| hospitals | No | |
| total_count | No | Total number of hospitals matching this query, across all pages, not just this page's hospitals.length. Compare against hospitals.length (plus any prior pages) before concluding the full hospital list has been seen - e.g. before answering 'does medprice.ai support any hospitals in state X' or similar completeness questions. |
| next_page_token | No | Opaque pagination token, empty when there are no more results. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds substantive behavioral context: default returns the full registry, pagination behavior with next_page_token, truncation meaning, and total_count as a completeness check. It also mentions geocoded coordinates where available and revision history, exceeding what annotations provide.
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 and front-loaded: first sentence states purpose and return fields, second covers default behavior, third explains pagination, fourth explains completeness checking. Every sentence earns its place, and the length is justified by the pagination complexity. 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?
Given the tool's moderate complexity (pagination) and the presence of an output schema, the description is highly complete. It explains the default registry size, how to handle next_page_token, how to verify completeness with total_count, and even provides an example use case (Iowa coverage). The agent has all needed context to operate the tool confidently.
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?
Both parameters (page_size, page_token) are already fully described in the schema with identical details (default 500, cap, opaque token, do not construct custom tokens). Since schema_description_coverage is 100%, the baseline is 3, and the tool description adds no new parameter-specific semantics beyond what the schema already provides.
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: 'Returns the hospitals supported by the medprice.ai API' with a specific list of fields. This verb+resource combination unambiguously identifies the operation, and the sibling tools (focused on costs/chargemaster) are clearly distinct from listing hospitals.
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 detailed usage guidance, particularly around pagination: how to use next_page_token, when to continue calling, and using total_count for completeness checks. It does not explicitly mention alternatives like 'use get_hospital_chargemaster_cost for cost data', but the purpose is so clear that usage context is implied. A brief exclusionary note would push it to 5.
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!
Sign in to create a connector for this server.