MedPrice AI

List hospital costs for a billing code

list_hospital_code_costs

Read-only

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.

Input Schema

TableJSON Schema

Name	Required	Description
`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.

Output Schema

TableJSON Schema

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.

Schema Changelog

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

Changed3 schema fields changedAug 13, 2026

changedInput schema / properties / page_size / description

Previous 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."

changedInput schema / properties / page_token / description

Previous 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."

addedOutput schema / properties / total_count

Added 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"
+}

AddedAug 13, 2026

TDQS

A4.9/5.0

Behavior5/5

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.

Conciseness5/5

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.

Completeness5/5

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.

Parameters4/5

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.

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 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.

Usage Guidelines5/5

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.

All MedPrice AI tools Inspect

Try in Browser

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.