Skip to main content
Glama

Server Details

Hosted MCP server exposing US hospital procedure cost data to AI assistants

If you are the author of this connector, you can claim ownership by verifying the domain or GitHub account it belongs to. Claimed connector authors can inspect health checks, view analytics, and manage their listing.
Status
Healthy
Uptime
100.0% over 63 days
Last Tested
Transport
Streamable HTTP · MCP 2025-11-25
URL
Repository
medprice-ai/mcp-medprice-ai
GitHub Stars
0
Server Listing
mcp-medprice-ai

TDQS

A4/5.0

Scored across 7 tools

Disambiguation5/5

Each tool targets a distinct purpose: discovery (list_hospitals, list_code_types, list_codes), single-point lookup (get_hospital_chargemaster_cost), batch lookup (batch_get_hospital_chargemaster_cost), cross-hospital comparison (list_hospital_code_costs), and aggregate distribution (get_code_price_distribution). The batch-vs-single and distribution-vs-list distinctions are explicitly clarified in descriptions, leaving no meaningful overlap despite the terse single-get description.

Naming Consistency5/5

All tools use consistent snake_case with a predictable verb_noun pattern (list_*, get_*, batch_get_*). The batch_ prefix is a clear modifier rather than a convention break, and no styles are mixed.

Tool Count5/5

Seven tools map cleanly to the domain's needs: three for discovery, three for cost lookup/comparison, and one for distribution analysis. No tool feels redundant, and the count is well within the ideal 3-15 range.

Completeness4/5

The surface covers discovery, single and batch lookups, cross-hospital comparison, and price distributions, leaving no dead ends for typical queries. Minor gap: no direct batch operation across multiple codes and multiple hospitals, and get_hospital_chargemaster_cost has a notably terse description compared to its peers.

Available Tools

7 tools
batch_get_hospital_chargemaster_costBatch get hospital chargemaster costsA
Read-only
Inspect

Looks up cost stats for several (code_type, code) pairs at one hospital (identified by hospital_id) in a single call - the batch counterpart to get_hospital_chargemaster_cost. Use this instead of calling get_hospital_chargemaster_cost once per code when pricing a fixed set of codes at one hospital (e.g. cross-linking a curated list of procedures on a hospital's page). Capped at 100 codes per call; a request over that is rejected with INVALID_ARGUMENT rather than silently truncated.

ParametersJSON Schema
NameRequiredDescriptionDefault
codesYesThe (code_type, code) pairs to price at this hospital - up to 100 entries. Results come back in this same order.
hospital_idYesOpaque hospital identifier from list_hospitals.
revision_idNoOptional. A revision_id from list_hospitals' per-hospital revisions array, to price that specific past revision instead of the hospital's latest one, applied to every code in this batch. Omit to use the latest revision.

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultsNoOne entry per requested code, in request order - found=false (not omitted) when this hospital has no data for that code.

TDQS

A4.7/5.0
Behavior4/5

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

Annotations already establish readOnly/non-destructive safety, so the bar is lower, yet the description still adds the 100-code cap and the important failure mode: over-limit requests are rejected with INVALID_ARGUMENT rather than silently truncated. It does not cover auth requirements or rate limits, but the cap and error semantics are substantive behavioral disclosure.

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?

Two tight sentences that lead with what the tool does and where it fits, followed by the practical limit. No filler, no repetition of schema details.

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?

With an output schema present, the description need not explain return values, and annotations cover the safety profile. The remaining agent-facing questions — when to batch vs. loop, and what happens at the limit — are both answered.

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; the description adds ordering semantics ('Results come back in this same order') and the batch cap of 100 entries, which the schema does not state. It does not explain the methodologies or revision_id parameters, which the schema already handles.

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?

States a specific verb+resource ('looks up cost stats'), the scope (several code_type/code pairs at one hospital), and explicitly positions itself as 'the batch counterpart to get_hospital_chargemaster_cost'. An agent can distinguish it from the singular sibling without opening either schema.

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?

Gives explicit when-to-use guidance ('when pricing a fixed set of codes at one hospital') and names the alternative to avoid ('instead of calling get_hospital_chargemaster_cost once per code'), with a concrete example (cross-linking a curated list on a hospital's page). Nothing is left to inference.

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

get_code_price_distributionGet price distribution for a billing codeA
Read-only
Inspect

Returns the distribution of every hospital's price for a code_type/code, computed server-side: min/p10/q1/median/q3/p90/max, standard deviation, a histogram, and the real hospital nearest each percentile. Use this instead of paging through list_hospital_code_costs when you want to know how prices spread across hospitals (e.g. "is $12k high for MS-DRG 788?" - pass reference_price to get the number of hospitals priced below it). All figures are in terms of the chosen statistic (default: each hospital's average price).

ParametersJSON Schema
NameRequiredDescriptionDefault
codeYes
bin_countNoNumber of histogram bars. Defaults to 16, capped at 200 (larger values are rejected).
code_typeYesCode system the billing code belongs to, e.g. APR-DRG, CDM, CPT, HCPCS, MS-DRG, RC.
statisticNoWhich per-hospital figure to distribute: each hospital's average (default), median, lowest filed price, or highest filed price.
methodologyNoPricing methodology. Omit to aggregate across all methodologies.
reference_priceNoOptional price to place on the distribution. When positive, hospitals_below_reference counts hospitals priced strictly below it. Negative values are rejected.
min_sample_countNoMinimum pricing sample size: only include hospitals whose price is backed by at least this many billing records (same semantics as list_hospital_code_costs). 0 (default) disables the filter. Negative values are rejected.

Output Schema

ParametersJSON Schema
NameRequiredDescription
q1No25th percentile.
q3No75th percentile.
maxNo
minNo
p10No
p90No
medianNo
std_devNoPopulation standard deviation of the per-hospital values.
q1_hospitalNoA real hospital and its price for the code, used to name a hospital at a percentile. Unset (absent or empty hospital_id) when hospital_count is 0.
q3_hospitalNoA real hospital and its price for the code, used to name a hospital at a percentile. Unset (absent or empty hospital_id) when hospital_count is 0.
histogram_hiNoUpper edge of the last bar: min(max, 1.35 * p90), or min + 1 when that is not above the minimum. Hospitals priced above this are counted in overflow_count.
histogram_loNoLower edge of the first histogram bar (the minimum).
max_hospitalNoA real hospital and its price for the code, used to name a hospital at a percentile. Unset (absent or empty hospital_id) when hospital_count is 0.
min_hospitalNoA real hospital and its price for the code, used to name a hospital at a percentile. Unset (absent or empty hospital_id) when hospital_count is 0.
p10_hospitalNoA real hospital and its price for the code, used to name a hospital at a percentile. Unset (absent or empty hospital_id) when hospital_count is 0.
p90_hospitalNoA real hospital and its price for the code, used to name a hospital at a percentile. Unset (absent or empty hospital_id) when hospital_count is 0.
histogram_binsNoHospital count per equal-width bar from histogram_lo to histogram_hi; the last bar includes its upper edge.
hospital_countNoHospitals with a positive value for the code on their latest revision (and at least min_sample_count samples, if set). 0 means every other field is unset.
overflow_countNoHospitals priced above histogram_hi.
median_hospitalNoA real hospital and its price for the code, used to name a hospital at a percentile. Unset (absent or empty hospital_id) when hospital_count is 0.
hospitals_below_referenceNoHospitals priced strictly below the request's reference_price; 0 when it was not set.

TDQS

A4.9/5.0
Behavior5/5

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

Beyond the annotations indicating it is read-only, the description details the exact output statistics computed ('min/p10/q1/median/q3/p90/max, standard deviation, a histogram'). It also clarifies that the figures relate to the 'chosen statistic' and explains the mechanics of server-side computation.

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 dense but highly efficient. It immediately front-loads the core function and then dedicates the second half to differentiation and practical usage examples, ensuring every sentence contributes maximum value.

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 high complexity (multiple parameters, statistical output, and a comparison to a sibling), the description is exceptionally complete. It addresses what the tool returns, how it calculates it, and when it should be selected.

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?

While the schema has high coverage (86%), the description adds significant functional meaning to the `reference_price` parameter by explaining that a positive value 'counts hospitals priced strictly below it.' This is crucial behavioral context beyond simple type definition.

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 uses a specific verb ("Returns the distribution") and clearly identifies the resource (prices for a code_type/code). Most importantly, it differentiates itself from the sibling tool by stating it should be used 'instead of paging through list_hospital_code_costs'.

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?

It provides explicit guidance on when to use the tool: 'when you want to know how prices spread across hospitals.' It also gives a specific, functional use case example involving `reference_price` (e.g., 'is $12k high for MS-DRG 788?').

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

get_hospital_chargemaster_costGet hospital chargemaster costC
Read-only
Inspect

Lookup hospital chargemaster cost

ParametersJSON Schema
NameRequiredDescriptionDefault
codeYes
code_typeYesCode 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_idYesOpaque hospital identifier from list_hospitals.
revision_idNoOptional. 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.
methodologiesNoPricing methodologies to price, one result per entry in request order. Omit or pass an empty array to get a single aggregate result across all methodologies.

Output Schema

ParametersJSON Schema
NameRequiredDescription
foundNoTrue if at least one entry in results was found.
resultsNoOne entry per requested methodology, in request order - or, when the methodologies filter was left empty, exactly one aggregate entry.
hospitalNoHospital name returned by the MedPrice AI backend.
hospital_idNoOpaque hospital identifier to use with get_hospital_chargemaster_cost or list_hospitals.

TDQS

C2.5/5.0
Behavior2/5

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description contributes no additional behavioral context such as pricing/edition semantics, revision handling, or multi-methodology behavior, all of which matter for a cost lookup.

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

Conciseness3/5

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

Four words are front-loaded and free of filler, but the text is under-specified rather than genuinely concise — it omits information an agent needs for a multi-parameter pricing lookup.

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

Completeness2/5

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

An output schema exists, so return values need not be described, but for a 5-parameter tool with a required code/code_type/hospital_id triple and optional revision and methodology filters, the description is too thin to orient an agent. Nothing clarifies cost semantics or how results differ from sibling listing tools.

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

Parameters3/5

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

Schema description coverage is 80%, so the schema already explains code_type, hospital_id, revision_id, and methodologies. The description adds no parameter meaning beyond the schema, so the baseline of 3 applies.

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

Purpose3/5

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

The description names a specific verb and resource ('Lookup hospital chargemaster cost'), so the basic purpose is discernible. However, it is essentially a rephrasing of the tool name/title and adds nothing that distinguishes it from the sibling batch_get_hospital_chargemaster_cost.

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

Usage Guidelines2/5

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

There is no guidance on when to use this tool versus batch_get_hospital_chargemaster_cost, list_hospital_code_costs, or list_codes. No prerequisites or exclusion conditions are stated.

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 typeA
Read-only
Inspect

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. Pass query to text-search codes/descriptions instead of listing a whole code_type. Pass hospital_id to restrict results to codes that one hospital actually reports.

ParametersJSON Schema
NameRequiredDescriptionDefault
sortNoOrdering 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_SORT_SAMPLE_COUNT_DESC sorts by largest network-wide pricing sample size first (sample_count_max, always network-wide regardless of hospital_id) - ranks by how many billing records actually back a code's pricing, rather than by how many hospitals merely report it. CODE_SORT_CODE_DESC is code-alphabetical, reverse order. CODE_SORT_RELEVANCE ranks best text match first (exact code, then code prefix, then description word-start, then description substring), ties broken by network-wide sample count descending, and is only meaningful - and the default - when query is set; without a query it behaves like CODE_SORT_SAMPLE_COUNT_DESC.
queryNoCase-insensitive text search: matches the code as a prefix, and substrings of the raw and AI-generated descriptions. Descriptions are only searched for queries of 4+ characters; shorter queries match the code prefix only. When set, code_type may be left empty to search across code types.
code_typeNoCode system to list codes for, e.g. "CPT". From list_code_types. May be left empty when query is set, to search across code types (excluding hospital-specific CDM and LOCAL codes) - CodeSummary.code_type tells the hits apart in that case.
page_sizeNoMaximum number of results to return. Defaults to 500, capped at 500.
page_tokenNoOpaque token from a previous list_codes response. Omit for the first page. Only valid with the same query/code_type/sort it was issued for.
hospital_idNoOptional hospital scoping (a hospital_id from list_hospitals): restricts results to codes that hospital actually reports on its latest revision, and makes sample_count_min/max/exact that hospital's own sample size for the code rather than the network-wide total. Unset (default) is network-wide. page_token is only valid with the same hospital_id it was issued for, same as query/code_type/sort.

Output Schema

ParametersJSON Schema
NameRequiredDescription
codesNo
total_countNoTotal number of matching codes across all pages.
next_page_tokenNoOpaque pagination token, empty when there are no more results.

TDQS

A4.5/5.0
Behavior4/5

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

Annotations already declare the safe read-only profile, and the description layers on real behavior: results are paginated, each row carries a hospital-report count, and the tool is meant as a discovery step. It does not itself explain the sort-mode semantics or the sample_count interplay (those live in the schema), so it stops short of maximal behavioral disclosure, but it adds meaningful 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.

Conciseness5/5

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

Purpose is front-loaded in the first sentence, followed by routing guidance and per-parameter hints, with no filler. Every sentence carries distinct, actionable information.

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?

With an output schema present, return values need not be re-explained, and the rich annotations cover safety. The description adds discovery context, pagination awareness, and QA-to-QA routing that complete the picture for calling this six-parameter listing tool correctly.

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

Parameters3/5

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

Schema description coverage is 100%, so every parameter (including the enum sort modes and the query/hospital_id interactions) is already fully documented in the input schema. The description only restates the query and hospital_id intent, adding no syntax or format detail the schema lacks. Baseline 3 is appropriate.

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?

Opens with a specific verb+resource: returns every distinct code under a given code_type, and enumerates what each result carries (chargemaster description, hospital count). It also names the sibling tools (get_hospital_chargemaster_cost, list_hospital_code_costs) it precedes, so an agent can place it without opening any schema.

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?

Gives explicit when-to-use framing ('discover which codes exist... before looking up prices'), names the alternatives, and states the conditions that switch modes: pass query to text-search instead of listing a whole code_type, pass hospital_id to scope to one hospital. Nothing is left to inference.

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 typesA
Read-only
Inspect

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.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

Output Schema

ParametersJSON Schema
NameRequiredDescription
code_typesNoOne entry per distinct code_type present in the catalog, most code-rich first. Unpaginated.

TDQS

A4.7/5.0
Behavior4/5

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.

Conciseness5/5

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.

Completeness5/5

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.

Parameters4/5

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.

Purpose5/5

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.

Usage Guidelines5/5

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 codeA
Read-only
Inspect

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.

ParametersJSON Schema
NameRequiredDescriptionDefault
codeYes
code_typeYesCode 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_sizeNoMaximum number of results to return. Defaults to 500 (covering every matching hospital in one call at the current registry size), capped at 500.
page_tokenNoOpaque token from a previous list_hospital_code_costs response's next_page_token field. Omit for the first page. Only valid with the same code_type/code/methodology/min_sample_count it was issued for.
methodologyNoPricing methodology. Omit to aggregate across all methodologies.
min_sample_countNoMinimum pricing sample size: only return hospitals whose price is backed by at least this many billing records (compared against the de-identified range's lower bound, so a '1 through 10' row counts as 1). 0 (default) disables the filter. Pass 1 to exclude hospitals with no real sample data at all (most filings report 0/0, indistinguishable from a genuine zero). total_count and next_page_token describe the filtered set. Negative values are rejected.

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultsNoOne 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_countNoTotal 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_tokenNoOpaque pagination token, empty when there are no more results.

TDQS

A4.8/5.0
Behavior5/5

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

Annotations already declare the safe read-only, non-destructive profile, and the description adds substantial context beyond them: default full-result behavior, the meaning of next_page_token, an explicit loop-until-empty pagination protocol, and a total_count completeness check. This is exactly the kind of operational context annotations cannot convey.

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

Conciseness4/5

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

Front-loads purpose, then the sibling alternative, then pagination guidance, with no filler. The pagination paragraph is somewhat verbose, but each clause (loop until empty, don't conclude 'no data', use total_count) carries non-redundant operational value.

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 return fields need not be explained, yet the description usefully highlights next_page_token and total_count semantics. Combined with the annotations and schema, an agent has everything needed to call this correctly and paginate reliably.

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 description coverage is high (83%), so the schema already documents most parameters, giving a baseline of 3. The description adds workflow meaning for page_token (pass the exact next_page_token value, same code_type/code context) and reinforces the code_type/code pairing, lifting it slightly above baseline.

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?

States a specific verb and resource ('returns cost stats for every hospital with a matching chargemaster entry for a code_type/code') and names the sibling it replaces (get_hospital_chargemaster_cost). An agent can distinguish it from the single-hospital variants without opening a schema.

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?

Explicitly says when to use this tool instead of the alternative ('instead of calling get_hospital_chargemaster_cost once per hospital when comparing prices... across hospitals') and gives a concrete example query. It also covers when to paginate and warns against the wrong behavior of stopping after one page.

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

list_hospitalsList supported hospitalsA
Read-only
Inspect

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, revision_id, and added_at - when medprice itself ingested that revision, as opposed to revision_date's source-file-reported update date). 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'.

ParametersJSON 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

ParametersJSON Schema
NameRequiredDescription
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.

TDQS

A5/5.0
Behavior5/5

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

Annotations already declare readOnlyHint=true, openWorldHint=false, and destructiveHint=false, and the description adds substantial behavioral context beyond them. It explains the pagination contract, the meaning of next_page_token, the total_count completeness check, and nuances such as revision ingestion timestamps versus source-reported dates.

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 long but every sentence adds necessary detail, from return fields to pagination to completeness checking. It is front-loaded with the core purpose and then systematically explains edge cases, so the structure supports agent comprehension.

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 tool's complexity, the description is complete: it covers what is returned, default behavior, pagination, completeness verification, and an example use case. The output schema exists, so return values do not need to be fully re-described, and nothing critical is missing.

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

Parameters5/5

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

Schema coverage is 100%, but the description still adds important semantics: page_size defaults to 500 and is capped at 500, and page_token must be the exact opaque token from a previous response. It explicitly warns not to construct or pass other values, which is valuable operational guidance.

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 clearly states the tool returns the hospitals supported by the medprice.ai API and enumerates the exact fields included, such as hospital_id, EIN, name, structured_locations, last_updated_on, and revision history. This makes its purpose unambiguous and distinguishes it from sibling tools like list_codes or get_hospital_chargemaster_cost.

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?

The description provides explicit usage guidance, including pagination behavior, how to handle next_page_token, and how to verify completeness using total_count. It even gives a concrete example of when to use this tool, such as answering whether medprice.ai covers hospitals in Iowa.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 1 tool update
    • Addedget_code_price_distribution
  2. 1 tool update
    • Changedlist_codes3 fields changed
      • changedInput schema / properties / query / description
        Previous value: -"Case-insensitive text search: matches the code as a prefix, and substrings of the raw and friendly descriptions. Descriptions are only searched for queries of 4+ characters; shorter queries match the code prefix only. When set, code_type may be left empty to search across code types."New value: +"Case-insensitive text search: matches the code as a prefix, and substrings of the raw and AI-generated descriptions. Descriptions are only searched for queries of 4+ characters; shorter queries match the code prefix only. When set, code_type may be left empty to search across code types."
      • addedOutput schema / properties / codes / items / properties / ai_description
        Added value: +{
        +  "description": "LLM-normalized, human-readable description. Empty when not yet backfilled - fall back to raw_description.",
        +  "type": "string"
        +}
      • removedOutput schema / properties / codes / items / properties / friendly_description
        Removed value: -{
        -  "description": "LLM-normalized, human-readable description. Empty when not yet backfilled - fall back to raw_description.",
        -  "type": "string"
        -}
  3. 4 tool updates
    • Changedbatch_get_hospital_chargemaster_cost6 fields changed
      • changedOutput schema / properties / results / items / properties / results / items / properties / cost / properties / sample_count_sum_max / description
        Previous value: -"Upper bound on the summed CMS sample-remittance count across contributing payer rows. Equal to sample_count_sum_min unless a de-identified '1 through 10' row narrowed it to a range."New value: +"Upper bound on the summed CMS sample-remittance count across contributing payer rows, as a decimal string (int64 - see protoLoaderOptions.longs). Equal to sample_count_sum_min unless a de-identified '1 through 10' row narrowed it to a range."
      • changedOutput schema / properties / results / items / properties / results / items / properties / cost / properties / sample_count_sum_max / type
        Previous value: -"integer"New value: +"string"
      • changedOutput schema / properties / results / items / properties / results / items / properties / cost / properties / sample_count_sum_min / description
        Previous value: -"Lower bound on the summed CMS sample-remittance count across contributing payer rows. Equal to sample_count_sum_max unless a de-identified '1 through 10' row narrowed it to a range."New value: +"Lower bound on the summed CMS sample-remittance count across contributing payer rows, as a decimal string (int64 - see protoLoaderOptions.longs). Equal to sample_count_sum_max unless a de-identified '1 through 10' row narrowed it to a range."
      • changedOutput schema / properties / results / items / properties / results / items / properties / cost / properties / sample_count_sum_min / type
        Previous value: -"integer"New value: +"string"
      • changedOutput schema / properties / results / items / properties / results / items / properties / cost / type
        Previous value: -"object"New value: +[
        +  "object",
        +  "null"
        +]
      • changedOutput schema / properties / results / items / properties / results / items / properties / description / type
        Previous value: -"object"New value: +[
        +  "object",
        +  "null"
        +]
    • Changedget_hospital_chargemaster_cost6 fields changed
      • changedOutput schema / properties / results / items / properties / cost / properties / sample_count_sum_max / description
        Previous value: -"Upper bound on the summed CMS sample-remittance count across contributing payer rows. Equal to sample_count_sum_min unless a de-identified '1 through 10' row narrowed it to a range."New value: +"Upper bound on the summed CMS sample-remittance count across contributing payer rows, as a decimal string (int64 - see protoLoaderOptions.longs). Equal to sample_count_sum_min unless a de-identified '1 through 10' row narrowed it to a range."
      • changedOutput schema / properties / results / items / properties / cost / properties / sample_count_sum_max / type
        Previous value: -"integer"New value: +"string"
      • changedOutput schema / properties / results / items / properties / cost / properties / sample_count_sum_min / description
        Previous value: -"Lower bound on the summed CMS sample-remittance count across contributing payer rows. Equal to sample_count_sum_max unless a de-identified '1 through 10' row narrowed it to a range."New value: +"Lower bound on the summed CMS sample-remittance count across contributing payer rows, as a decimal string (int64 - see protoLoaderOptions.longs). Equal to sample_count_sum_max unless a de-identified '1 through 10' row narrowed it to a range."
      • changedOutput schema / properties / results / items / properties / cost / properties / sample_count_sum_min / type
        Previous value: -"integer"New value: +"string"
      • changedOutput schema / properties / results / items / properties / cost / type
        Previous value: -"object"New value: +[
        +  "object",
        +  "null"
        +]
      • changedOutput schema / properties / results / items / properties / description / type
        Previous value: -"object"New value: +[
        +  "object",
        +  "null"
        +]
    • Changedlist_codes4 fields changed
      • changedOutput schema / properties / codes / items / properties / sample_count_max / description
        Previous value: -"Upper bound on the CMS sample-remittance count, same network-wide-vs-hospital-scoped convention as sample_count_min. Equal to sample_count_min unless a de-identified '1 through 10' row narrowed it to a range."New value: +"Upper bound on the CMS sample-remittance count, as a decimal string (int64 - see protoLoaderOptions.longs), same network-wide-vs-hospital-scoped convention as sample_count_min. Equal to sample_count_min unless a de-identified '1 through 10' row narrowed it to a range."
      • changedOutput schema / properties / codes / items / properties / sample_count_max / type
        Previous value: -"integer"New value: +"string"
      • changedOutput schema / properties / codes / items / properties / sample_count_min / description
        Previous value: -"Lower bound on the CMS sample-remittance count. By default (no hospital_id in the request) this sums every reporting hospital's contributing payer rows, network-wide; when the request scopes to a hospital_id, it's that one hospital's own sample count for this code instead. Equal to sample_count_max unless a de-identified '1 through 10' row narrowed it to a range."New value: +"Lower bound on the CMS sample-remittance count, as a decimal string (int64 - see protoLoaderOptions.longs). By default (no hospital_id in the request) this sums every reporting hospital's contributing payer rows, network-wide; when the request scopes to a hospital_id, it's that one hospital's own sample count for this code instead. Equal to sample_count_max unless a de-identified '1 through 10' row narrowed it to a range."
      • changedOutput schema / properties / codes / items / properties / sample_count_min / type
        Previous value: -"integer"New value: +"string"
    • Changedlist_hospital_code_costs6 fields changed
      • changedOutput schema / properties / results / items / properties / results / items / properties / cost / properties / sample_count_sum_max / description
        Previous value: -"Upper bound on the summed CMS sample-remittance count across contributing payer rows. Equal to sample_count_sum_min unless a de-identified '1 through 10' row narrowed it to a range."New value: +"Upper bound on the summed CMS sample-remittance count across contributing payer rows, as a decimal string (int64 - see protoLoaderOptions.longs). Equal to sample_count_sum_min unless a de-identified '1 through 10' row narrowed it to a range."
      • changedOutput schema / properties / results / items / properties / results / items / properties / cost / properties / sample_count_sum_max / type
        Previous value: -"integer"New value: +"string"
      • changedOutput schema / properties / results / items / properties / results / items / properties / cost / properties / sample_count_sum_min / description
        Previous value: -"Lower bound on the summed CMS sample-remittance count across contributing payer rows. Equal to sample_count_sum_max unless a de-identified '1 through 10' row narrowed it to a range."New value: +"Lower bound on the summed CMS sample-remittance count across contributing payer rows, as a decimal string (int64 - see protoLoaderOptions.longs). Equal to sample_count_sum_max unless a de-identified '1 through 10' row narrowed it to a range."
      • changedOutput schema / properties / results / items / properties / results / items / properties / cost / properties / sample_count_sum_min / type
        Previous value: -"integer"New value: +"string"
      • changedOutput schema / properties / results / items / properties / results / items / properties / cost / type
        Previous value: -"object"New value: +[
        +  "object",
        +  "null"
        +]
      • changedOutput schema / properties / results / items / properties / results / items / properties / description / type
        Previous value: -"object"New value: +[
        +  "object",
        +  "null"
        +]
  4. 3 tool updates
    • Addedbatch_get_hospital_chargemaster_cost
    • Changedlist_codes15 fields changed
      • changedInput schema / properties / code_type / description
        Previous value: -"Code system to list codes for, e.g. \"CPT\". From list_code_types."New value: +"Code system to list codes for, e.g. \"CPT\". From list_code_types. May be left empty when query is set, to search across code types (excluding hospital-specific CDM and LOCAL codes) - CodeSummary.code_type tells the hits apart in that case."
      • addedInput schema / properties / hospital_id
        Added value: +{
        +  "description": "Optional hospital scoping (a hospital_id from list_hospitals): restricts results to codes that hospital actually reports on its latest revision, and makes sample_count_min/max/exact that hospital's own sample size for the code rather than the network-wide total. Unset (default) is network-wide. page_token is only valid with the same hospital_id it was issued for, same as query/code_type/sort.",
        +  "type": "string"
        +}
      • changedInput schema / properties / page_token / description
        Previous value: -"Opaque token from a previous list_codes response. Omit for the first page."New value: +"Opaque token from a previous list_codes response. Omit for the first page. Only valid with the same query/code_type/sort it was issued for."
      • addedInput schema / properties / query
        Added value: +{
        +  "description": "Case-insensitive text search: matches the code as a prefix, and substrings of the raw and friendly descriptions. Descriptions are only searched for queries of 4+ characters; shorter queries match the code prefix only. When set, code_type may be left empty to search across code types.",
        +  "type": "string"
        +}
      • changedInput schema / properties / sort / description
        Previous value: -"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_SORT_SAMPLE_COUNT_DESC sorts by largest pricing sample size first (total_sample_count_max) - ranks by how many billing records actually back a code's pricing, rather than by how many hospitals merely report it. CODE_SORT_CODE_DESC is code-alphabetical, reverse order."New value: +"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_SORT_SAMPLE_COUNT_DESC sorts by largest network-wide pricing sample size first (sample_count_max, always network-wide regardless of hospital_id) - ranks by how many billing records actually back a code's pricing, rather than by how many hospitals merely report it. CODE_SORT_CODE_DESC is code-alphabetical, reverse order. CODE_SORT_RELEVANCE ranks best text match first (exact code, then code prefix, then description word-start, then description substring), ties broken by network-wide sample count descending, and is only meaningful - and the default - when query is set; without a query it behaves like CODE_SORT_SAMPLE_COUNT_DESC."
      • changedInput schema / properties / sort / enum
        Previous value: -[
        -  "CODE_SORT_UNSPECIFIED",
        -  "CODE_SORT_HOSPITAL_COUNT_DESC",
        -  "CODE_SORT_SAMPLE_COUNT_DESC",
        -  "CODE_SORT_CODE_DESC"
        -]New value: +[
        +  "CODE_SORT_UNSPECIFIED",
        +  "CODE_SORT_HOSPITAL_COUNT_DESC",
        +  "CODE_SORT_SAMPLE_COUNT_DESC",
        +  "CODE_SORT_CODE_DESC",
        +  "CODE_SORT_RELEVANCE"
        +]
      • changedInput schema / required
        Previous value: -[
        -  "code_type"
        -]New value: +[]
      • addedOutput schema / properties / codes / items / properties / code_type
        Added value: +{
        +  "description": "This code's type, e.g. \"CPT\". Always set - distinguishes hits when query was searched across code types (code_type left empty in the request).",
        +  "type": "string"
        +}
      • addedOutput schema / properties / codes / items / properties / friendly_description
        Added value: +{
        +  "description": "LLM-normalized, human-readable description. Empty when not yet backfilled - fall back to raw_description.",
        +  "type": "string"
        +}
      • addedOutput schema / properties / codes / items / properties / sample_count_exact
        Added value: +{
        +  "description": "True iff sample_count_min == sample_count_max, i.e. no contributing row was a de-identified '1 through 10' range.",
        +  "type": "boolean"
        +}
      • addedOutput schema / properties / codes / items / properties / sample_count_max
        Added value: +{
        +  "description": "Upper bound on the CMS sample-remittance count, same network-wide-vs-hospital-scoped convention as sample_count_min. Equal to sample_count_min unless a de-identified '1 through 10' row narrowed it to a range.",
        +  "type": "integer"
        +}
      • addedOutput schema / properties / codes / items / properties / sample_count_min
        Added value: +{
        +  "description": "Lower bound on the CMS sample-remittance count. By default (no hospital_id in the request) this sums every reporting hospital's contributing payer rows, network-wide; when the request scopes to a hospital_id, it's that one hospital's own sample count for this code instead. Equal to sample_count_max unless a de-identified '1 through 10' row narrowed it to a range.",
        +  "type": "integer"
        +}
      • removedOutput schema / properties / codes / items / properties / total_sample_count_exact
        Removed value: -{
        -  "description": "True iff total_sample_count_min == total_sample_count_max, i.e. no contributing hospital's sample_count was a de-identified '1 through 10' range.",
        -  "type": "boolean"
        -}
      • removedOutput schema / properties / codes / items / properties / total_sample_count_max
        Removed value: -{
        -  "description": "Upper bound on the summed CMS sample-remittance count across every reporting hospital's contributing payer rows. Equal to total_sample_count_min unless a de-identified '1 through 10' row narrowed it to a range.",
        -  "type": "integer"
        -}
      • removedOutput schema / properties / codes / items / properties / total_sample_count_min
        Removed value: -{
        -  "description": "Lower bound on the summed CMS sample-remittance count across every reporting hospital's contributing payer rows. Equal to total_sample_count_max unless a de-identified '1 through 10' row narrowed it to a range.",
        -  "type": "integer"
        -}
    • Changedlist_hospital_code_costs2 fields changed
      • addedInput schema / properties / min_sample_count
        Added value: +{
        +  "description": "Minimum pricing sample size: only return hospitals whose price is backed by at least this many billing records (compared against the de-identified range's lower bound, so a '1 through 10' row counts as 1). 0 (default) disables the filter. Pass 1 to exclude hospitals with no real sample data at all (most filings report 0/0, indistinguishable from a genuine zero). total_count and next_page_token describe the filtered set. Negative values are rejected.",
        +  "type": "integer"
        +}
      • changedInput schema / properties / page_token / description
        Previous 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."New value: +"Opaque token from a previous list_hospital_code_costs response's next_page_token field. Omit for the first page. Only valid with the same code_type/code/methodology/min_sample_count it was issued for."
  5. 1 tool update
    • Changedlist_codes5 fields changed
      • changedInput schema / properties / sort / description
        Previous value: -"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."New value: +"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_SORT_SAMPLE_COUNT_DESC sorts by largest pricing sample size first (total_sample_count_max) - ranks by how many billing records actually back a code's pricing, rather than by how many hospitals merely report it. CODE_SORT_CODE_DESC is code-alphabetical, reverse order."
      • changedInput schema / properties / sort / enum
        Previous value: -[
        -  "CODE_SORT_UNSPECIFIED",
        -  "CODE_SORT_HOSPITAL_COUNT_DESC"
        -]New value: +[
        +  "CODE_SORT_UNSPECIFIED",
        +  "CODE_SORT_HOSPITAL_COUNT_DESC",
        +  "CODE_SORT_SAMPLE_COUNT_DESC",
        +  "CODE_SORT_CODE_DESC"
        +]
      • addedOutput schema / properties / codes / items / properties / total_sample_count_exact
        Added value: +{
        +  "description": "True iff total_sample_count_min == total_sample_count_max, i.e. no contributing hospital's sample_count was a de-identified '1 through 10' range.",
        +  "type": "boolean"
        +}
      • addedOutput schema / properties / codes / items / properties / total_sample_count_max
        Added value: +{
        +  "description": "Upper bound on the summed CMS sample-remittance count across every reporting hospital's contributing payer rows. Equal to total_sample_count_min unless a de-identified '1 through 10' row narrowed it to a range.",
        +  "type": "integer"
        +}
      • addedOutput schema / properties / codes / items / properties / total_sample_count_min
        Added value: +{
        +  "description": "Lower bound on the summed CMS sample-remittance count across every reporting hospital's contributing payer rows. Equal to total_sample_count_max unless a de-identified '1 through 10' row narrowed it to a range.",
        +  "type": "integer"
        +}
  6. 2 tool updates
    • Changedget_hospital_chargemaster_cost3 fields changed
      • addedOutput schema / properties / results / items / properties / cost / properties / sample_count_exact
        Added value: +{
        +  "description": "True iff sample_count_sum_min == sample_count_sum_max, i.e. no contributing row was a de-identified '1 through 10' range.",
        +  "type": "boolean"
        +}
      • addedOutput schema / properties / results / items / properties / cost / properties / sample_count_sum_max
        Added value: +{
        +  "description": "Upper bound on the summed CMS sample-remittance count across contributing payer rows. Equal to sample_count_sum_min unless a de-identified '1 through 10' row narrowed it to a range.",
        +  "type": "integer"
        +}
      • addedOutput schema / properties / results / items / properties / cost / properties / sample_count_sum_min
        Added value: +{
        +  "description": "Lower bound on the summed CMS sample-remittance count across contributing payer rows. Equal to sample_count_sum_max unless a de-identified '1 through 10' row narrowed it to a range.",
        +  "type": "integer"
        +}
    • Changedlist_hospital_code_costs3 fields changed
      • addedOutput schema / properties / results / items / properties / results / items / properties / cost / properties / sample_count_exact
        Added value: +{
        +  "description": "True iff sample_count_sum_min == sample_count_sum_max, i.e. no contributing row was a de-identified '1 through 10' range.",
        +  "type": "boolean"
        +}
      • addedOutput schema / properties / results / items / properties / results / items / properties / cost / properties / sample_count_sum_max
        Added value: +{
        +  "description": "Upper bound on the summed CMS sample-remittance count across contributing payer rows. Equal to sample_count_sum_min unless a de-identified '1 through 10' row narrowed it to a range.",
        +  "type": "integer"
        +}
      • addedOutput schema / properties / results / items / properties / results / items / properties / cost / properties / sample_count_sum_min
        Added value: +{
        +  "description": "Lower bound on the summed CMS sample-remittance count across contributing payer rows. Equal to sample_count_sum_max unless a de-identified '1 through 10' row narrowed it to a range.",
        +  "type": "integer"
        +}
  7. 2 tool updates
    • Changedget_hospital_chargemaster_cost7 fields changed
      • addedInput schema / properties / methodologies
        Added value: +{
        +  "description": "Pricing methodologies to price, one result per entry in request order. Omit or pass an empty array to get a single aggregate result across all methodologies.",
        +  "items": {
        +    "enum": [
        +      "case rate",
        +      "fee schedule",
        +      "other",
        +      "percent of total billed charges",
        +      "per diem"
        +    ],
        +    "type": "string"
        +  },
        +  "type": "array"
        +}
      • removedInput schema / properties / methodology
        Removed value: -{
        -  "description": "Pricing methodology. Omit to aggregate across all methodologies.",
        -  "enum": [
        -    "case rate",
        -    "fee schedule",
        -    "other",
        -    "percent of total billed charges",
        -    "per diem"
        -  ],
        -  "type": "string"
        -}
      • removedOutput schema / properties / cost
        Removed value: -{
        -  "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"
        -}
      • removedOutput schema / properties / description
        Removed value: -{
        -  "properties": {
        -    "code_description": {
        -      "type": "string"
        -    },
        -    "hospital_name": {
        -      "type": "string"
        -    },
        -    "location": {
        -      "type": "string"
        -    },
        -    "methodology_note": {
        -      "type": "string"
        -    }
        -  },
        -  "type": "object"
        -}
      • changedOutput schema / properties / found / description
        Previous value: -"Whether a matching chargemaster cost record was found."New value: +"True if at least one entry in results was found."
      • addedOutput schema / properties / hospital_id
        Added value: +{
        +  "description": "Opaque hospital identifier to use with get_hospital_chargemaster_cost or list_hospitals.",
        +  "type": "string"
        +}
      • addedOutput schema / properties / results
        Added value: +{
        +  "description": "One entry per requested methodology, in request order - or, when the methodologies filter was left empty, exactly one aggregate entry.",
        +  "items": {
        +    "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 for this methodology.",
        +        "type": "boolean"
        +      },
        +      "methodology": {
        +        "description": "Methodology this entry is scoped to. Empty when aggregated across all methodologies (the request's methodology filter was left empty).",
        +        "type": "string"
        +      }
        +    },
        +    "type": "object"
        +  },
        +  "type": "array"
        +}
    • Changedlist_hospital_code_costs4 fields changed
      • removedOutput schema / properties / results / items / properties / cost
        Removed value: -{
        -  "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"
        -}
      • removedOutput schema / properties / results / items / properties / description
        Removed value: -{
        -  "properties": {
        -    "code_description": {
        -      "type": "string"
        -    },
        -    "hospital_name": {
        -      "type": "string"
        -    },
        -    "location": {
        -      "type": "string"
        -    },
        -    "methodology_note": {
        -      "type": "string"
        -    }
        -  },
        -  "type": "object"
        -}
      • changedOutput schema / properties / results / items / properties / found / description
        Previous value: -"Whether a matching chargemaster cost record was found."New value: +"True if at least one entry in results was found."
      • addedOutput schema / properties / results / items / properties / results
        Added value: +{
        +  "description": "One entry per requested methodology, in request order - or, when the methodology filter was left empty, exactly one aggregate entry.",
        +  "items": {
        +    "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 for this methodology.",
        +        "type": "boolean"
        +      },
        +      "methodology": {
        +        "description": "Methodology this entry is scoped to. Empty when aggregated across all methodologies (the request's methodology filter was left empty).",
        +        "type": "string"
        +      }
        +    },
        +    "type": "object"
        +  },
        +  "type": "array"
        +}
  8. 1 tool update
    • Changedlist_hospitals1 field changed
      • addedOutput schema / properties / hospitals / items / properties / revisions / items / properties / added_at
        Added value: +{
        +  "description": "ISO-8601 UTC timestamp of when medprice itself ingested this revision (server-set at insert time) - not derived from revision_date/last_updated_on, which reflects the source file's own self-reported update date and can lag well behind actual ingestion. Useful for sorting/highlighting by 'recently added to medprice' rather than 'recently updated by the hospital'.",
        +  "type": "string"
        +}
  9. 1 tool update
    • Changedlist_codes1 field changed
      • addedInput schema / properties / sort
        Added 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"
        +}
  10. 2 tool updates
    • Addedlist_code_types
    • Addedlist_codes
  11. 2 tool updates
    • Changedlist_hospital_code_costs3 fields changed
      • 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"
        +}
    • Changedlist_hospitals3 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"
        +}
  12. 3 tool updates
    • Changedget_hospital_chargemaster_cost1 field changed
      • addedInput schema / properties / revision_id
        Added 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"
        +}
    • Addedlist_hospital_code_costs
    • Changedlist_hospitals1 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"
        +}
  13. 1 tool update
    • Changedlist_hospitals2 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"
        +}
  14. 1 tool update
    • Changedlist_hospitals2 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"
        +}
  15. 2 tool updates
    • Changedget_hospital_chargemaster_cost1 field changed
      • 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"
        +}
    • Changedlist_hospitals1 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"
        +}
  16. 1 tool update
    • Changedget_hospital_chargemaster_cost2 fields changed
      • addedInput schema / properties / hospital_id
        Added value: +{
        +  "description": "Opaque hospital identifier from list_hospitals.",
        +  "type": "string"
        +}
      • changedInput schema / required
        Previous value: -[
        -  "code_type",
        -  "code"
        -]New value: +[
        +  "hospital_id",
        +  "code_type",
        +  "code"
        +]

Related MCP Connectors

Related MCP Servers

  • F
    license
    Not graded
    quality
    D
    maintenance
    A multi-purpose MCP server for AI-powered healthcare assistance that processes clinical data through configurable LLM providers. Maintains webhook endpoints for patient data processing with PostgreSQL logging and OpenAPI documentation.
    -
  • A
    license
    A
    quality
    A
    maintenance
    An MCP server that exposes a DICOMweb-compliant DICOM archive to AI assistants. It lets any MCP-capable client search studies, series and instances, inspect metadata, read Structured and Encapsulated PDF Reports, and render image frames — all through natural language.
    9
    14 npm
    4
    MIT
Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.