MedPrice AI
Server Details
Hosted MCP server exposing US hospital procedure cost data to AI assistants
- 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
Scored across 7 tools
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.
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.
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.
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 toolsbatch_get_hospital_chargemaster_costBatch get hospital chargemaster costsARead-onlyInspect
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.
| Name | Required | Description | Default |
|---|---|---|---|
| codes | Yes | The (code_type, code) pairs to price at this hospital - up to 100 entries. Results come back in this same order. | |
| hospital_id | Yes | Opaque hospital identifier from list_hospitals. | |
| 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, applied to every code in this batch. Omit to use the latest revision. |
Output Schema
| Name | Required | Description |
|---|---|---|
| results | No | One entry per requested code, in request order - found=false (not omitted) when this hospital has no data for that code. |
TDQS
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.
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.
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.
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.
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.
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 codeARead-onlyInspect
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).
| Name | Required | Description | Default |
|---|---|---|---|
| code | Yes | ||
| bin_count | No | Number of histogram bars. Defaults to 16, capped at 200 (larger values are rejected). | |
| code_type | Yes | Code system the billing code belongs to, e.g. APR-DRG, CDM, CPT, HCPCS, MS-DRG, RC. | |
| statistic | No | Which per-hospital figure to distribute: each hospital's average (default), median, lowest filed price, or highest filed price. | |
| methodology | No | Pricing methodology. Omit to aggregate across all methodologies. | |
| reference_price | No | Optional price to place on the distribution. When positive, hospitals_below_reference counts hospitals priced strictly below it. Negative values are rejected. | |
| min_sample_count | No | Minimum 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
| Name | Required | Description |
|---|---|---|
| q1 | No | 25th percentile. |
| q3 | No | 75th percentile. |
| max | No | |
| min | No | |
| p10 | No | |
| p90 | No | |
| median | No | |
| std_dev | No | Population standard deviation of the per-hospital values. |
| q1_hospital | No | A 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_hospital | No | A 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_hi | No | Upper 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_lo | No | Lower edge of the first histogram bar (the minimum). |
| max_hospital | No | A 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_hospital | No | A 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_hospital | No | A 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_hospital | No | A 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_bins | No | Hospital count per equal-width bar from histogram_lo to histogram_hi; the last bar includes its upper edge. |
| hospital_count | No | Hospitals 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_count | No | Hospitals priced above histogram_hi. |
| median_hospital | No | A 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_reference | No | Hospitals priced strictly below the request's reference_price; 0 when it was not set. |
TDQS
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.
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.
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.
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.
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.
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 costCRead-onlyInspect
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. | |
| 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. | |
| methodologies | No | 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. |
Output Schema
| Name | Required | Description |
|---|---|---|
| found | No | True if at least one entry in results was found. |
| results | No | One entry per requested methodology, in request order - or, when the methodologies filter was left empty, exactly one aggregate entry. |
| hospital | No | Hospital name returned by the MedPrice AI backend. |
| hospital_id | No | Opaque hospital identifier to use with get_hospital_chargemaster_cost or list_hospitals. |
TDQS
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.
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.
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.
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.
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.
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 typeARead-onlyInspect
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.
| 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_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. | |
| query | No | 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. | |
| code_type | No | 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. | |
| 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. Only valid with the same query/code_type/sort it was issued for. | |
| hospital_id | No | 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. |
Output Schema
| 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. |
TDQS
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.
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.
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.
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.
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.
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 typesARead-onlyInspect
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 | |||
Output Schema
| Name | Required | Description |
|---|---|---|
| code_types | No | One entry per distinct code_type present in the catalog, most code-rich first. Unpaginated. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds 'Unpaginated' and the fact that it returns aggregated counts and reports, which are not in the annotations. This adds meaningful behavioral context beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences: the first states exactly what is returned (with examples) and the second gives the intended usage scenario. No fluff, front-loaded with the most important information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter tool with an output schema, the description adequately covers purpose, usage, and key behavioral notes (unpaginated). It also names the relevant sibling for further drilling, making it self-sufficient for an agent to decide when to invoke it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, so the baseline per the rubric is 4. The description does not explain any parameters because there are none; the schema coverage is 100% (trivially) and no additional parameter semantics are needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns every distinct code_type (e.g., CPT, MS-DRG) with associated cost data, code counts, and hospital reports. It distinguishes itself from the sibling tool list_codes by explicitly framing this as an aggregation-level listing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says when to use it ('Use this to discover which code systems have data') and points to the next step ('before drilling into list_codes'), which clearly differentiates it from the primary sibling. It also notes 'Unpaginated' as a usage caveat.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_hospital_code_costsList hospital costs for a billing codeARead-onlyInspect
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. Only valid with the same code_type/code/methodology/min_sample_count it was issued for. | |
| methodology | No | Pricing methodology. Omit to aggregate across all methodologies. | |
| min_sample_count | No | 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. |
Output 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. |
TDQS
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.
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.
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.
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.
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.
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 hospitalsARead-onlyInspect
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'.
| 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. |
Output Schema
| 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. |
TDQS
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.
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.
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.
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.
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.
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 tool update
- Added
get_code_price_distribution
1 tool update
- Changed
list_codes3 fields changed- changed
Input schema / properties / query / descriptionPrevious 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." - added
Output schema / properties / codes / items / properties / ai_descriptionAdded value: +{ + "description": "LLM-normalized, human-readable description. Empty when not yet backfilled - fall back to raw_description.", + "type": "string" +} - removed
Output schema / properties / codes / items / properties / friendly_descriptionRemoved value: -{ - "description": "LLM-normalized, human-readable description. Empty when not yet backfilled - fall back to raw_description.", - "type": "string" -}
4 tool updates
- Changed
batch_get_hospital_chargemaster_cost6 fields changed- changed
Output schema / properties / results / items / properties / results / items / properties / cost / properties / sample_count_sum_max / descriptionPrevious 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." - changed
Output schema / properties / results / items / properties / results / items / properties / cost / properties / sample_count_sum_max / typePrevious value: -"integer"New value: +"string" - changed
Output schema / properties / results / items / properties / results / items / properties / cost / properties / sample_count_sum_min / descriptionPrevious 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." - changed
Output schema / properties / results / items / properties / results / items / properties / cost / properties / sample_count_sum_min / typePrevious value: -"integer"New value: +"string" - changed
Output schema / properties / results / items / properties / results / items / properties / cost / typePrevious value: -"object"New value: +[ + "object", + "null" +] - changed
Output schema / properties / results / items / properties / results / items / properties / description / typePrevious value: -"object"New value: +[ + "object", + "null" +]
- Changed
get_hospital_chargemaster_cost6 fields changed- changed
Output schema / properties / results / items / properties / cost / properties / sample_count_sum_max / descriptionPrevious 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." - changed
Output schema / properties / results / items / properties / cost / properties / sample_count_sum_max / typePrevious value: -"integer"New value: +"string" - changed
Output schema / properties / results / items / properties / cost / properties / sample_count_sum_min / descriptionPrevious 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." - changed
Output schema / properties / results / items / properties / cost / properties / sample_count_sum_min / typePrevious value: -"integer"New value: +"string" - changed
Output schema / properties / results / items / properties / cost / typePrevious value: -"object"New value: +[ + "object", + "null" +] - changed
Output schema / properties / results / items / properties / description / typePrevious value: -"object"New value: +[ + "object", + "null" +]
- Changed
list_codes4 fields changed- changed
Output schema / properties / codes / items / properties / sample_count_max / descriptionPrevious 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." - changed
Output schema / properties / codes / items / properties / sample_count_max / typePrevious value: -"integer"New value: +"string" - changed
Output schema / properties / codes / items / properties / sample_count_min / descriptionPrevious 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." - changed
Output schema / properties / codes / items / properties / sample_count_min / typePrevious value: -"integer"New value: +"string"
- Changed
list_hospital_code_costs6 fields changed- changed
Output schema / properties / results / items / properties / results / items / properties / cost / properties / sample_count_sum_max / descriptionPrevious 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." - changed
Output schema / properties / results / items / properties / results / items / properties / cost / properties / sample_count_sum_max / typePrevious value: -"integer"New value: +"string" - changed
Output schema / properties / results / items / properties / results / items / properties / cost / properties / sample_count_sum_min / descriptionPrevious 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." - changed
Output schema / properties / results / items / properties / results / items / properties / cost / properties / sample_count_sum_min / typePrevious value: -"integer"New value: +"string" - changed
Output schema / properties / results / items / properties / results / items / properties / cost / typePrevious value: -"object"New value: +[ + "object", + "null" +] - changed
Output schema / properties / results / items / properties / results / items / properties / description / typePrevious value: -"object"New value: +[ + "object", + "null" +]
3 tool updates
- Added
batch_get_hospital_chargemaster_cost - Changed
list_codes15 fields changed- changed
Input schema / properties / code_type / descriptionPrevious 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." - added
Input schema / properties / hospital_idAdded 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" +} - changed
Input schema / properties / page_token / descriptionPrevious 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." - added
Input schema / properties / queryAdded 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" +} - changed
Input schema / properties / sort / descriptionPrevious 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." - changed
Input schema / properties / sort / enumPrevious 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" +] - changed
Input schema / requiredPrevious value: -[ - "code_type" -]New value: +[] - added
Output schema / properties / codes / items / properties / code_typeAdded 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" +} - added
Output schema / properties / codes / items / properties / friendly_descriptionAdded value: +{ + "description": "LLM-normalized, human-readable description. Empty when not yet backfilled - fall back to raw_description.", + "type": "string" +} - added
Output schema / properties / codes / items / properties / sample_count_exactAdded 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" +} - added
Output schema / properties / codes / items / properties / sample_count_maxAdded 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" +} - added
Output schema / properties / codes / items / properties / sample_count_minAdded 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" +} - removed
Output schema / properties / codes / items / properties / total_sample_count_exactRemoved 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" -} - removed
Output schema / properties / codes / items / properties / total_sample_count_maxRemoved 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" -} - removed
Output schema / properties / codes / items / properties / total_sample_count_minRemoved 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" -}
- Changed
list_hospital_code_costs2 fields changed- added
Input schema / properties / min_sample_countAdded 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" +} - changed
Input schema / properties / page_token / descriptionPrevious 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."
1 tool update
- Changed
list_codes5 fields changed- changed
Input schema / properties / sort / descriptionPrevious 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." - changed
Input schema / properties / sort / enumPrevious 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" +] - added
Output schema / properties / codes / items / properties / total_sample_count_exactAdded 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" +} - added
Output schema / properties / codes / items / properties / total_sample_count_maxAdded 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" +} - added
Output schema / properties / codes / items / properties / total_sample_count_minAdded 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" +}
2 tool updates
- Changed
get_hospital_chargemaster_cost3 fields changed- added
Output schema / properties / results / items / properties / cost / properties / sample_count_exactAdded 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" +} - added
Output schema / properties / results / items / properties / cost / properties / sample_count_sum_maxAdded 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" +} - added
Output schema / properties / results / items / properties / cost / properties / sample_count_sum_minAdded 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" +}
- Changed
list_hospital_code_costs3 fields changed- added
Output schema / properties / results / items / properties / results / items / properties / cost / properties / sample_count_exactAdded 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" +} - added
Output schema / properties / results / items / properties / results / items / properties / cost / properties / sample_count_sum_maxAdded 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" +} - added
Output schema / properties / results / items / properties / results / items / properties / cost / properties / sample_count_sum_minAdded 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" +}
2 tool updates
- Changed
get_hospital_chargemaster_cost7 fields changed- added
Input schema / properties / methodologiesAdded 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" +} - removed
Input schema / properties / methodologyRemoved 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" -} - removed
Output schema / properties / costRemoved 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" -} - removed
Output schema / properties / descriptionRemoved value: -{ - "properties": { - "code_description": { - "type": "string" - }, - "hospital_name": { - "type": "string" - }, - "location": { - "type": "string" - }, - "methodology_note": { - "type": "string" - } - }, - "type": "object" -} - changed
Output schema / properties / found / descriptionPrevious value: -"Whether a matching chargemaster cost record was found."New value: +"True if at least one entry in results was found." - added
Output schema / properties / hospital_idAdded value: +{ + "description": "Opaque hospital identifier to use with get_hospital_chargemaster_cost or list_hospitals.", + "type": "string" +} - added
Output schema / properties / resultsAdded 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" +}
- Changed
list_hospital_code_costs4 fields changed- removed
Output schema / properties / results / items / properties / costRemoved 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" -} - removed
Output schema / properties / results / items / properties / descriptionRemoved value: -{ - "properties": { - "code_description": { - "type": "string" - }, - "hospital_name": { - "type": "string" - }, - "location": { - "type": "string" - }, - "methodology_note": { - "type": "string" - } - }, - "type": "object" -} - changed
Output schema / properties / results / items / properties / found / descriptionPrevious value: -"Whether a matching chargemaster cost record was found."New value: +"True if at least one entry in results was found." - added
Output schema / properties / results / items / properties / resultsAdded 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" +}
1 tool update
- Changed
list_hospitals1 field changed- added
Output schema / properties / hospitals / items / properties / revisions / items / properties / added_atAdded 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" +}
1 tool update
- Changed
list_codes1 field changed- added
Input 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" +}
2 tool updates
- Added
list_code_types - Added
list_codes
2 tool updates
- Changed
list_hospital_code_costs3 fields changed- changed
Input 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." - changed
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." - added
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" +}
- Changed
list_hospitals3 fields changed- changed
Input 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." - changed
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." - added
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" +}
3 tool updates
- Changed
get_hospital_chargemaster_cost1 field changed- added
Input 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" +}
- Added
list_hospital_code_costs - Changed
list_hospitals1 field changed- added
Output 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" +}
1 tool update
- Changed
list_hospitals2 fields changed- added
Output schema / properties / hospitals / items / properties / locations / descriptionAdded value: +"Deprecated - use structured_locations instead." - added
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" +}
1 tool update
- Changed
list_hospitals2 fields changed- changed
Output 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." - added
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" +}
2 tool updates
- Changed
get_hospital_chargemaster_cost1 field changed- changed
Output 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" +}
- Changed
list_hospitals1 field changed- changed
Output 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" +}
1 tool update
- Changed
get_hospital_chargemaster_cost2 fields changed- added
Input schema / properties / hospital_idAdded value: +{ + "description": "Opaque hospital identifier from list_hospitals.", + "type": "string" +} - changed
Input schema / requiredPrevious value: -[ - "code_type", - "code" -]New value: +[ + "hospital_id", + "code_type", + "code" +]
Related MCP Connectors
Free hosted MCP server: US healthcare procedure cost estimates and provider pricing. No API key.
Hosted MCP server for Cliniko — patients, appointments, availability, and invoices for AI agents.
- UnifAPIOAuthcom.unifapi
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.
Related MCP Servers
- AlicenseNot gradedqualityCmaintenanceA remote MCP server that lets an LLM explore, query, aggregate, and benchmark the ~234 datasets in the CMS Provider Data Catalog — hospitals, dialysis facilities, nursing homes, home health, hospice, physicians, and more — in plain language.AGPL 3.0
- FlicenseNot gradedqualityDmaintenanceA 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.-
- FlicenseNot gradedqualityCmaintenanceMCP server that exposes health metrics from the Sapphire Wellness App to AI assistants, enabling natural language queries for activity, blood pressure, glucose, heart rate, sleep, and SpO2 data.-
- AlicenseAqualityAmaintenanceAn 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.914 npm4MIT
Glama MCP Gateway
Add one secure layer between your agents and this server.