Hosted MCP server exposing US hospital procedure cost data to AI assistants
Scored across 5 tools
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.
Lookup 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.
Returns 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 |
|---|---|---|---|
| sort | No | Ordering for the returned codes. CODE_SORT_UNSPECIFIED (default) sorts code-alphabetical. CODE_SORT_HOSPITAL_COUNT_DESC sorts most-hospitals-reporting first, for pre-sorted 'top codes' pages. | |
| 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 mark this as read-only and non-destructive. The description adds useful behavioral context beyond that: results are paginated, codes are distinct, and each result includes the raw chargemaster description and hospital count. No contradiction with 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 with no filler. The first sentence front-loads what the tool returns and how it paginates; the second gives the use case and alternatives. 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?
For a read-only listing tool with a full output schema, fully documented parameters, and clear annotations, this description is complete. It tells the agent what the tool returns, how results are paginated, and when to invoke it relative to sibling tools.
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 four parameters. The description reinforces code_type and pagination conceptually, but it does not add parameter-level meaning beyond what the schema provides, so the baseline of 3 is appropriate.
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 states a specific verb and resource: 'Returns every distinct code catalogued under a given code_type.' It also names sibling tools that do price lookups, clearly distinguishing this code-discovery tool from them.
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 explicitly says when to use this tool: 'Use this to discover which codes exist under a code system... before looking up prices.' It names the alternatives get_hospital_chargemaster_cost and list_hospital_code_costs, so an agent knows exactly how to route.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns 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.
Returns 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.
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'.
| 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, 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.
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.
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.
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.
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.
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.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
list_codes1 field changedInput schema / properties / sortAdded value: +{
+ "description": "Ordering for the returned codes. CODE_SORT_UNSPECIFIED (default) sorts code-alphabetical. CODE_SORT_HOSPITAL_COUNT_DESC sorts most-hospitals-reporting first, for pre-sorted 'top codes' pages.",
+ "enum": [
+ "CODE_SORT_UNSPECIFIED",
+ "CODE_SORT_HOSPITAL_COUNT_DESC"
+ ],
+ "type": "string"
+}list_code_typeslist_codeslist_hospital_code_costs3 fields changedInput schema / properties / page_size / descriptionPrevious value: -"Maximum number of results to return. Defaults to 20, capped at 100."New value: +"Maximum number of results to return. Defaults to 500 (covering every matching hospital in one call at the current registry size), capped at 500."Input schema / properties / page_token / descriptionPrevious value: -"Opaque token from a previous list_hospital_code_costs response. Omit for the first page."New value: +"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."Output schema / properties / total_countAdded value: +{
+ "description": "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.",
+ "type": "integer"
+}list_hospitals3 fields changedInput schema / properties / page_size / descriptionPrevious 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."Input schema / properties / page_token / descriptionPrevious 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."Output schema / properties / total_countAdded 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"
+}get_hospital_chargemaster_cost1 field changedInput schema / properties / revision_idAdded value: +{
+ "description": "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.",
+ "type": "string"
+}list_hospital_code_costslist_hospitals1 field changedOutput schema / properties / hospitals / items / properties / revisions / items / properties / revision_idAdded 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"
+}list_hospitals2 fields changedOutput schema / properties / hospitals / items / properties / locations / descriptionAdded value: +"Deprecated - use structured_locations instead."Output schema / properties / hospitals / items / properties / structured_locationsAdded 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"
+}list_hospitals2 fields changedOutput schema / properties / hospitals / items / properties / last_updated_on / descriptionPrevious 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."Output schema / properties / hospitals / items / properties / revisionsAdded 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"
+}get_hospital_chargemaster_cost1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "cost": {
+ "properties": {
+ "avg": {
+ "type": "string"
+ },
+ "code": {
+ "type": "string"
+ },
+ "code_type": {
+ "type": "string"
+ },
+ "max": {
+ "type": "string"
+ },
+ "median": {
+ "type": "string"
+ },
+ "min": {
+ "type": "string"
+ },
+ "std_dev": {
+ "type": "string"
+ }
+ },
+ "type": "object"
+ },
+ "description": {
+ "properties": {
+ "code_description": {
+ "type": "string"
+ },
+ "hospital_name": {
+ "type": "string"
+ },
+ "location": {
+ "type": "string"
+ },
+ "methodology_note": {
+ "type": "string"
+ }
+ },
+ "type": "object"
+ },
+ "found": {
+ "description": "Whether a matching chargemaster cost record was found.",
+ "type": "boolean"
+ },
+ "hospital": {
+ "description": "Hospital name returned by the MedPrice AI backend.",
+ "type": "string"
+ }
+ },
+ "type": "object"
+}list_hospitals1 field 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"
+}get_hospital_chargemaster_cost2 fields changedInput schema / properties / hospital_idAdded value: +{
+ "description": "Opaque hospital identifier from list_hospitals.",
+ "type": "string"
+}Input schema / requiredPrevious value: -[
- "code_type",
- "code"
-]New value: +[
+ "hospital_id",
+ "code_type",
+ "code"
+]list_hospitalsget_hospital_chargemaster_costget_hospital_procedure_costget_hospital_procedure_costClaiming 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, then choose Claim with GitHub. An organization namespace such as io.github.acme/server also needs that organization to have installed the Glama AI GitHub App and approved its permissions, because GitHub discloses organization membership only to apps it has installed. Use HTTP or DNS when it has not.
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!
Hosted MCP server for Cliniko — patients, appointments, availability, and invoices for AI agents.
Hosted MCP server for live public-data APIs and Skills for AI agents.
Hosted MCP server for the Healthie EHR & telehealth API: patients, appointments, charting, tasks.
Hosted MCP server for LLM cost estimation, model comparison, and budget-aware routing.
Add one secure layer between your agents and this server.
