Hosted MCP server exposing US hospital procedure cost data to AI assistants
Scored across 5 tools
The two cost-retrieval tools (get_hospital_chargemaster_cost and list_hospital_code_costs) target similar data, but descriptions clearly delineate single-hospital lookup vs cross-hospital comparison. The catalog tools (list_code_types, list_codes) and registry tool (list_hospitals) are clearly distinct.
All names use snake_case with a consistent verb_noun construction (list_codes, list_code_types, list_hospitals, list_hospital_code_costs, get_hospital_chargemaster_cost). The lone 'get' verb vs 'list' is a minor stylistic deviation but still predictable.
Five tools is well-scoped for a hospital price-lookup domain spanning discovery (code types, codes, hospitals) and cost retrieval (single and aggregate). Each tool has a clear, non-redundant role.
The surface covers the full drill-down path: discover code types, discover codes, discover hospitals, then fetch costs single or comparably. Minor gaps like a single-hospital detail lookup or keyword procedure search exist but are workable via list_hospitals.
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. |
| 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. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, covering the safety profile. The description adds no additional behavioral context such as how revision_id or methodologies affect the result, or what an aggregate result means. It simply restates the lookup nature without going beyond the annotations, so it provides no extra value in this dimension.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded phrase with no filler words. It is concise and to the point, though it errs on the side of being too minimal. It earns its place but leaves room for more useful content without sacrificing conciseness.
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?
The tool has 5 parameters, an output schema, and sibling tools. The description provides only a one-line overview, which is minimally sufficient given the detailed schema and output schema. However, it does not explain how to use the tool relative to siblings, the behavior of methodologies, or what the returned cost represents. Clear gaps remain, so it is adequate but not complete.
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% (4 of 5 parameters have descriptions), so the baseline is 3. The description itself does not add any parameter-level meaning; it does not mention code_type, hospital_id, revision_id, or methodologies. The schema already carries the parameter semantics, and the description does not compensate for the undocumented 'code' parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb ('lookup') and resource ('hospital chargemaster cost'). It is not a tautology, but it does not explicitly differentiate from the sibling tool list_hospital_code_costs, which likely also deals with hospital costs. The verb 'lookup' suggests a single lookup rather than a list, but this is not spelled out.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus the sibling tools. There is no mention of alternatives, prerequisites, or contextual scenarios such as 'use this to get a specific price vs list_hospital_code_costs to enumerate prices'. The agent is left to infer usage from the name and schema.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns every distinct code catalogued under a given code_type, paginated, with each code's raw chargemaster description and the number of hospitals reporting it. Use this to discover which codes exist under a code system (e.g. all CPT codes) before looking up prices with get_hospital_chargemaster_cost or list_hospital_code_costs.
| Name | Required | Description | Default |
|---|---|---|---|
| sort | No | Ordering for the returned codes. CODE_SORT_UNSPECIFIED (default) sorts code-alphabetical. CODE_SORT_HOSPITAL_COUNT_DESC sorts most-hospitals-reporting first, for pre-sorted 'top codes' pages. CODE_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. | |
| code_type | Yes | Code system to list codes for, e.g. "CPT". From list_code_types. | |
| page_size | No | Maximum number of results to return. Defaults to 500, capped at 500. | |
| page_token | No | Opaque token from a previous list_codes response. Omit for the first page. |
| Name | Required | Description |
|---|---|---|
| codes | No | |
| total_count | No | Total number of matching codes across all pages. |
| next_page_token | No | Opaque pagination token, empty when there are no more results. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, non-destructive, and non-openWorld, so the safety profile is covered. The description adds pagination awareness and the fact that each code carries a raw description and hospital count, which is modestly useful, but the return-value details are also carried by the output schema, so added behavioral value is limited.
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: the first delivers the return contract, the second the usage routing. The most decision-relevant scoping information is front-loaded with zero waste.
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 re-explained, and the description still covers pagination and the workflow position relative to siblings. For a read-only list tool with full schema coverage, nothing an agent needs to call it correctly 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 description coverage is 100%, including a fully documented sort enum and the code_type reference to list_code_types, so the schema does the heavy lifting. The description adds no parameter meaning beyond what the schema already provides, making the baseline 3 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?
Names a specific verb and resource ('Returns every distinct code catalogued under a given code_type') and explicitly lists the returned fields, so the agent knows exactly what this produces. It is clearly distinguishable from sibling tools like get_hospital_chargemaster_cost and 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?
Explicitly states when to use it ('to discover which codes exist under a code system (e.g. all CPT codes)') and names the downstream alternatives it precedes ('before looking up prices with get_hospital_chargemaster_cost or list_hospital_code_costs'). This is a complete when-to-use and relationship statement.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns every distinct code_type (e.g. CPT, MS-DRG) with catalogued cost data, along with each type's distinct code count and total hospital reports. Unpaginated. Use this to discover which code systems have data before drilling into list_codes.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| code_types | No | One entry per distinct code_type present in the catalog, most code-rich first. Unpaginated. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds 'Unpaginated' and the fact that it returns aggregated counts and reports, which are not in the annotations. This adds meaningful behavioral context beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences: the first states exactly what is returned (with examples) and the second gives the intended usage scenario. No fluff, front-loaded with the most important information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter tool with an output schema, the description adequately covers purpose, usage, and key behavioral notes (unpaginated). It also names the relevant sibling for further drilling, making it self-sufficient for an agent to decide when to invoke it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, so the baseline per the rubric is 4. The description does not explain any parameters because there are none; the schema coverage is 100% (trivially) and no additional parameter semantics are needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns every distinct code_type (e.g., CPT, MS-DRG) with associated cost data, code counts, and hospital reports. It distinguishes itself from the sibling tool list_codes by explicitly framing this as an aggregation-level listing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says when to use it ('Use this to discover which code systems have data') and points to the next step ('before drilling into list_codes'), which clearly differentiates it from the primary sibling. It also notes 'Unpaginated' as a usage caveat.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns cost stats for every hospital with a matching chargemaster entry for a code_type/code. Use this instead of calling get_hospital_chargemaster_cost once per hospital when comparing prices for the same procedure across hospitals (e.g. "which hospital has the cheapest MS-DRG 652?"). Defaults to returning every matching hospital (currently at most a few hundred) in one call. If the response's next_page_token is non-empty, the result set was truncated: call this tool again passing that exact value as page_token to get the next page, and keep doing so until next_page_token is empty - do not stop after one page and conclude a hospital has no data for this code. The response's total_count field (total across all pages) can be compared against how many results you've accumulated so far as a completeness check.
| Name | Required | Description | Default |
|---|---|---|---|
| code | Yes | ||
| code_type | Yes | Code system the chargemaster/billing code belongs to, e.g. APR-DRG, CDM, CPT, HCPCS, MS-DRG, RC. Hospitals may also support additional proprietary code types not listed here. | |
| page_size | No | Maximum number of results to return. Defaults to 500 (covering every matching hospital in one call at the current registry size), capped at 500. | |
| page_token | No | Opaque token from a previous list_hospital_code_costs response's next_page_token field. Omit for the first page. Do not pass any other value (e.g. an offset or cursor you construct yourself) here. | |
| methodology | No | Pricing methodology. Omit to aggregate across all methodologies. |
| Name | Required | Description |
|---|---|---|
| results | No | One entry per hospital with a matching chargemaster entry for this code (its latest revision only) - hospitals with no data for this code are omitted, not returned with found=false. |
| total_count | No | Total number of matching results across all pages, not just this page's results.length. Compare against results.length (plus any prior pages) to confirm you have the complete set before concluding a hospital or code has no data. |
| next_page_token | No | Opaque pagination token, empty when there are no more results. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, and the description adds valuable behavioral context beyond that: it returns every matching hospital by default, may truncate results, and requires following next_page_token until empty. It also explains total_count as a completeness check, which is exactly the kind of behavior an agent needs to know.
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 every sentence earns its place: purpose, alternative use case, default behavior, pagination rule, and completeness check. It is front-loaded with the core purpose and then gives necessary operational details without fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema exists and annotations cover safety, the description supplies the remaining critical context: when to choose this tool, how pagination works, and how to verify completeness via total_count. Nothing an agent needs to invoke the tool correctly 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 description coverage is 80%, so the schema already documents most parameters. The description reinforces page_token usage and total_count semantics but does not add substantial new meaning for the parameters themselves beyond what the schema provides. This meets the baseline for high schema coverage without exceeding it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Returns cost stats for every hospital with a matching chargemaster entry for a code_type/code.' It also names the sibling alternative (get_hospital_chargemaster_cost) and clarifies the cross-hospital comparison use case, so an agent can distinguish this tool from its siblings without inspecting schemas.
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 to use this tool instead of calling get_hospital_chargemaster_cost once per hospital when comparing prices across hospitals, providing a concrete example. It also gives detailed pagination instructions, including how to handle next_page_token and why not to stop after one page. This is clear, actionable guidance with an explicit alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns the hospitals supported by the medprice.ai API, with their hospital_id (opaque handle), EIN, name, structured_locations (addresses with geocoded coordinates where available), last_updated_on, and revision history (with per-revision has_payer_data, 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. |
| Name | Required | Description |
|---|---|---|
| hospitals | No | |
| total_count | No | Total number of hospitals matching this query, across all pages, not just this page's hospitals.length. Compare against hospitals.length (plus any prior pages) before concluding the full hospital list has been seen - e.g. before answering 'does medprice.ai support any hospitals in state X' or similar completeness questions. |
| next_page_token | No | Opaque pagination token, empty when there are no more results. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, 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.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
list_codes5 fields changedInput 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."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"
+]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"
+}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"
+}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"
+}get_hospital_chargemaster_cost3 fields changedOutput 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"
+}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"
+}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"
+}list_hospital_code_costs3 fields changedOutput 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"
+}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"
+}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"
+}get_hospital_chargemaster_cost7 fields changedInput 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"
+}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"
-}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"
-}Output schema / properties / descriptionRemoved value: -{
- "properties": {
- "code_description": {
- "type": "string"
- },
- "hospital_name": {
- "type": "string"
- },
- "location": {
- "type": "string"
- },
- "methodology_note": {
- "type": "string"
- }
- },
- "type": "object"
-}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."Output schema / properties / hospital_idAdded value: +{
+ "description": "Opaque hospital identifier to use with get_hospital_chargemaster_cost or list_hospitals.",
+ "type": "string"
+}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"
+}list_hospital_code_costs4 fields changedOutput 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"
-}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"
-}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."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"
+}list_hospitals1 field changedOutput 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"
+}list_codes1 field changedInput schema / properties / sortAdded value: +{
+ "description": "Ordering for the returned codes. CODE_SORT_UNSPECIFIED (default) sorts code-alphabetical. CODE_SORT_HOSPITAL_COUNT_DESC sorts most-hospitals-reporting first, for pre-sorted 'top codes' pages.",
+ "enum": [
+ "CODE_SORT_UNSPECIFIED",
+ "CODE_SORT_HOSPITAL_COUNT_DESC"
+ ],
+ "type": "string"
+}list_code_typeslist_codeslist_hospital_code_costs3 fields changedInput schema / properties / page_size / descriptionPrevious value: -"Maximum number of results to return. Defaults to 20, capped at 100."New value: +"Maximum number of results to return. Defaults to 500 (covering every matching hospital in one call at the current registry size), capped at 500."Input schema / properties / page_token / descriptionPrevious value: -"Opaque token from a previous list_hospital_code_costs response. Omit for the first page."New value: +"Opaque token from a previous list_hospital_code_costs response's next_page_token field. Omit for the first page. Do not pass any other value (e.g. an offset or cursor you construct yourself) here."Output schema / properties / total_countAdded value: +{
+ "description": "Total number of matching results across all pages, not just this page's results.length. Compare against results.length (plus any prior pages) to confirm you have the complete set before concluding a hospital or code has no data.",
+ "type": "integer"
+}list_hospitals3 fields changedInput schema / properties / page_size / descriptionPrevious value: -"Maximum number of hospitals to return. Defaults to 20, capped at 100."New value: +"Maximum number of hospitals to return. Defaults to 500 (covering the entire current registry in one call), capped at 500."Input schema / properties / page_token / descriptionPrevious value: -"Opaque token from a previous list_hospitals response. Omit for the first page."New value: +"Opaque token from a previous list_hospitals response's next_page_token field. Omit for the first page. Do not pass any other value (e.g. an offset or cursor you construct yourself) here."Output schema / properties / total_countAdded value: +{
+ "description": "Total number of hospitals matching this query, across all pages, not just this page's hospitals.length. Compare against hospitals.length (plus any prior pages) before concluding the full hospital list has been seen - e.g. before answering 'does medprice.ai support any hospitals in state X' or similar completeness questions.",
+ "type": "integer"
+}get_hospital_chargemaster_cost1 field changedInput schema / properties / revision_idAdded value: +{
+ "description": "Optional. A revision_id from list_hospitals' per-hospital revisions array, to price that specific past revision instead of the hospital's latest one. Omit to use the latest revision.",
+ "type": "string"
+}list_hospital_code_costslist_hospitals1 field changedOutput schema / properties / hospitals / items / properties / revisions / items / properties / revision_idAdded value: +{
+ "description": "Opaque handle for this specific revision - pass back as revision_id to get_hospital_chargemaster_cost to price this revision instead of the hospital's latest one.",
+ "type": "string"
+}list_hospitals2 fields changedOutput schema / properties / hospitals / items / properties / locations / descriptionAdded value: +"Deprecated - use structured_locations instead."Output schema / properties / hospitals / items / properties / structured_locationsAdded value: +{
+ "description": "Same addresses as locations, plus geocoded coordinates where available.",
+ "items": {
+ "properties": {
+ "address": {
+ "type": "string"
+ },
+ "lat": {
+ "type": "number"
+ },
+ "lng": {
+ "type": "number"
+ },
+ "precision": {
+ "description": "Geocoding precision: STREET is a full street-address match, CITY is a city/state fallback, UNKNOWN means not yet geocoded or precision wasn't recorded.",
+ "enum": [
+ "LOCATION_PRECISION_UNKNOWN",
+ "LOCATION_PRECISION_STREET",
+ "LOCATION_PRECISION_CITY"
+ ],
+ "type": "string"
+ }
+ },
+ "type": "object"
+ },
+ "type": "array"
+}list_hospitals2 fields changedOutput schema / properties / hospitals / items / properties / last_updated_on / descriptionPrevious value: -"ISO-8601 date the source file was last updated."New value: +"ISO-8601 date the source file was last updated. Duplicates the last (most recent) entry in revisions."Output schema / properties / hospitals / items / properties / revisionsAdded value: +{
+ "description": "Every known revision of this hospital's filing, oldest first. Usually a single entry.",
+ "items": {
+ "properties": {
+ "has_payer_data": {
+ "description": "Whether this revision included payer-specific negotiated-rate data, as opposed to gross/cash price only.",
+ "type": "boolean"
+ },
+ "revision_date": {
+ "description": "ISO-8601 date this revision's source file was last updated on.",
+ "type": "string"
+ }
+ },
+ "type": "object"
+ },
+ "type": "array"
+}get_hospital_chargemaster_cost1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "cost": {
+ "properties": {
+ "avg": {
+ "type": "string"
+ },
+ "code": {
+ "type": "string"
+ },
+ "code_type": {
+ "type": "string"
+ },
+ "max": {
+ "type": "string"
+ },
+ "median": {
+ "type": "string"
+ },
+ "min": {
+ "type": "string"
+ },
+ "std_dev": {
+ "type": "string"
+ }
+ },
+ "type": "object"
+ },
+ "description": {
+ "properties": {
+ "code_description": {
+ "type": "string"
+ },
+ "hospital_name": {
+ "type": "string"
+ },
+ "location": {
+ "type": "string"
+ },
+ "methodology_note": {
+ "type": "string"
+ }
+ },
+ "type": "object"
+ },
+ "found": {
+ "description": "Whether a matching chargemaster cost record was found.",
+ "type": "boolean"
+ },
+ "hospital": {
+ "description": "Hospital name returned by the MedPrice AI backend.",
+ "type": "string"
+ }
+ },
+ "type": "object"
+}list_hospitals1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "hospitals": {
+ "items": {
+ "properties": {
+ "ein": {
+ "description": "Employer Identification Number for the hospital legal entity.",
+ "type": "string"
+ },
+ "hospital_id": {
+ "description": "Opaque hospital identifier to use with get_hospital_chargemaster_cost.",
+ "type": "string"
+ },
+ "hospital_name": {
+ "type": "string"
+ },
+ "last_updated_on": {
+ "description": "ISO-8601 date the source file was last updated.",
+ "type": "string"
+ },
+ "locations": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ }
+ },
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "next_page_token": {
+ "description": "Opaque pagination token, empty when there are no more results.",
+ "type": "string"
+ }
+ },
+ "type": "object"
+}get_hospital_chargemaster_cost2 fields changedInput schema / properties / hospital_idAdded value: +{
+ "description": "Opaque hospital identifier from list_hospitals.",
+ "type": "string"
+}Input schema / requiredPrevious value: -[
- "code_type",
- "code"
-]New value: +[
+ "hospital_id",
+ "code_type",
+ "code"
+]list_hospitalsget_hospital_chargemaster_costget_hospital_procedure_costget_hospital_procedure_costHosted MCP server for Cliniko — patients, appointments, availability, and invoices for AI agents.
Hosted MCP server for live public-data APIs and Skills for AI agents.
Hosted MCP server for the Healthie EHR & telehealth API: patients, appointments, charting, tasks.
Hosted MCP server for LLM cost estimation, model comparison, and budget-aware routing.
Add one secure layer between your agents and this server.
