Skip to main content
Glama

List supported hospitals

list_hospitals
Read-only

Returns the hospitals supported by the medprice.ai API, with their hospital_id (opaque handle), 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'.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
page_sizeNoMaximum number of hospitals to return. Defaults to 500 (covering the entire current registry in one call), capped at 500.
page_tokenNoOpaque 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.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
hospitalsNo
total_countNoTotal 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_tokenNoOpaque pagination token, empty when there are no more results.

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. Changed3 schema fields changed
    • changedInput schema / properties / page_size / description
      Previous value: -"Maximum number of hospitals to return. Defaults to 20, capped at 100."New value: +"Maximum number of hospitals to return. Defaults to 500 (covering the entire current registry in one call), capped at 500."
    • changedInput schema / properties / page_token / description
      Previous value: -"Opaque token from a previous list_hospitals response. Omit for the first page."New value: +"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."
    • addedOutput schema / properties / total_count
      Added value: +{
      +  "description": "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.",
      +  "type": "integer"
      +}
  2. Changed1 schema field changed
    • addedOutput schema / properties / hospitals / items / properties / revisions / items / properties / revision_id
      Added value: +{
      +  "description": "Opaque handle for this specific revision - pass back as revision_id to get_hospital_chargemaster_cost to price this revision instead of the hospital's latest one.",
      +  "type": "string"
      +}
  3. Changed2 schema fields changed
    • addedOutput schema / properties / hospitals / items / properties / locations / description
      Added value: +"Deprecated - use structured_locations instead."
    • addedOutput schema / properties / hospitals / items / properties / structured_locations
      Added value: +{
      +  "description": "Same addresses as locations, plus geocoded coordinates where available.",
      +  "items": {
      +    "properties": {
      +      "address": {
      +        "type": "string"
      +      },
      +      "lat": {
      +        "type": "number"
      +      },
      +      "lng": {
      +        "type": "number"
      +      },
      +      "precision": {
      +        "description": "Geocoding precision: STREET is a full street-address match, CITY is a city/state fallback, UNKNOWN means not yet geocoded or precision wasn't recorded.",
      +        "enum": [
      +          "LOCATION_PRECISION_UNKNOWN",
      +          "LOCATION_PRECISION_STREET",
      +          "LOCATION_PRECISION_CITY"
      +        ],
      +        "type": "string"
      +      }
      +    },
      +    "type": "object"
      +  },
      +  "type": "array"
      +}
  4. Changed2 schema fields changed
    • changedOutput schema / properties / hospitals / items / properties / last_updated_on / description
      Previous value: -"ISO-8601 date the source file was last updated."New value: +"ISO-8601 date the source file was last updated. Duplicates the last (most recent) entry in revisions."
    • addedOutput schema / properties / hospitals / items / properties / revisions
      Added value: +{
      +  "description": "Every known revision of this hospital's filing, oldest first. Usually a single entry.",
      +  "items": {
      +    "properties": {
      +      "has_payer_data": {
      +        "description": "Whether this revision included payer-specific negotiated-rate data, as opposed to gross/cash price only.",
      +        "type": "boolean"
      +      },
      +      "revision_date": {
      +        "description": "ISO-8601 date this revision's source file was last updated on.",
      +        "type": "string"
      +      }
      +    },
      +    "type": "object"
      +  },
      +  "type": "array"
      +}
  5. Changed1 schema field changed
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
      +  "properties": {
      +    "hospitals": {
      +      "items": {
      +        "properties": {
      +          "ein": {
      +            "description": "Employer Identification Number for the hospital legal entity.",
      +            "type": "string"
      +          },
      +          "hospital_id": {
      +            "description": "Opaque hospital identifier to use with get_hospital_chargemaster_cost.",
      +            "type": "string"
      +          },
      +          "hospital_name": {
      +            "type": "string"
      +          },
      +          "last_updated_on": {
      +            "description": "ISO-8601 date the source file was last updated.",
      +            "type": "string"
      +          },
      +          "locations": {
      +            "items": {
      +              "type": "string"
      +            },
      +            "type": "array"
      +          }
      +        },
      +        "type": "object"
      +      },
      +      "type": "array"
      +    },
      +    "next_page_token": {
      +      "description": "Opaque pagination token, empty when there are no more results.",
      +      "type": "string"
      +    }
      +  },
      +  "type": "object"
      +}
  6. Added

TDQS

A4.7/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true and destructiveHint=false, and the description adds substantial behavior beyond them: the default 'entire registry in one call,' the precise pagination contract (pass next_page_token back verbatim as page_token, loop until empty, never conclude after one page), and total_count as a cross-page completeness check. It even discloses registry scale and the opaque nature of hospital_id, leaving no major behavioral trait implicit.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Purpose is front-loaded in the first sentence, followed by default behavior, then pagination, then completeness checking in a logical progression. The longer sentences are dense with operational value — the explicit 'do not stop after one page and conclude the list is complete' warning is precisely the kind of detail that earns its length for an agent.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so the return shape does not need to be re-explained, yet the description still names the key fields. The real complexity of this tool — pagination looping, truncation detection, and completeness verification — is fully specified, and the safety profile is carried by the annotations. Nothing needed for a correct invocation is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3; both page_size and page_token are already documented there. The description exceeds the baseline by tying page_size's default to full-registry coverage and by reinforcing that page_token must be the exact next_page_token from a prior response, with an explicit warning against constructing your own cursor.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific verb+resource — 'Returns the hospitals supported by the medprice.ai API' — and enumerates the exact fields returned (hospital_id, EIN, name, structured_locations, last_updated_on, revision history). The hospital-registry domain is self-evidently distinct from sibling tools focused on codes and costs, and the title reinforces the same purpose.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides clear operational context: it states the default behavior (full registry in one call), instructs the agent to keep paging via next_page_token until empty, and tells it to use total_count as a completeness check before answering coverage questions. However, it never explicitly names sibling alternatives or states when-not-to-use-this-tool, so it stops short of the 5 bar.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.