Search source-labeled hospital prices, CPT codes, providers, and healthcare cost estimates.
Scored across 12 tools
Several pricing tools (get_entity_prices, get_hospital_pricing, get_market_pricing, get_pricing_estimate) overlap in returning hospital/price data, and search_entities vs search_hospitals both locate hospitals. Descriptions provide selection guidance, but an agent could still misselect without careful reading.
All tool names use snake_case with a consistent verb_noun pattern (get_*, search_*, explain_*, submit_*, suggest_*). No mixing of conventions; names are predictable and readable.
12 tools is well within the appropriate 3-15 range for a pricing lookup service. Each tool maps to a distinct action, though a few pricing variants could potentially be consolidated.
Core pricing workflow is covered: code lookup, entity/hospital/provider search, price retrieval, estimates, market benchmarks, source explanations, and a correction submission path. Minor gaps include no bulk hospital comparison or insurance-specific out-of-pocket tool, but the surface is largely complete.
Explain the source labels, provenance, confidence, and caveats behind Loa prices for one hospital or provider entity. Use this when an agent needs to tell a user why prices are MRF-published, Loa-reviewed, estimated, or unavailable.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | Exact Loa entity slug from search_entities. | |
| limit | No | Maximum number of prices to inspect, default 50, max 100. | |
| cpt_codes | No | Optional CPT codes to explain. If omitted, explains current indexed prices. |
| Name | Required | Description |
|---|---|---|
| entity | Yes | |
| caveats | Yes | |
| cpt_codes | Yes | |
| provenance | Yes | |
| price_count | Yes | |
| source_summary | Yes | |
| comparable_mrf_price_count | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds behavioral context by specifying the content of the explanation (source labels, provenance, confidence, caveats), which goes beyond the annotations without contradicting them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two sentences that immediately convey the tool's purpose and usage. There is no wasted text, and the key information is front-loaded.
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 moderate complexity and the presence of an output schema (not shown), the description adequately covers what the tool does and when to use it. It mentions the types of information provided (source labels, provenance, confidence, caveats), which is sufficient for an agent to decide to invoke it. However, it could benefit from a brief mention of the output format or structure, but the output schema compensates.
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% with all three parameters having descriptions in the input schema. The tool description adds overall context but does not provide additional meaning beyond what the schema already offers for each parameter, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: explaining source labels, provenance, confidence, and caveats behind Loa prices for a single entity. It distinguishes itself from sibling tools like get_entity_prices (which retrieves prices) and get_pricing_estimate (which estimates) by focusing on the provenance and explanation of price sources.
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 states when to use the tool: 'when an agent needs to tell a user why prices are MRF-published, Loa-reviewed, estimated, or unavailable.' This provides clear guidance, though it doesn't mention when not to use it or list specific alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return source-labeled prices for a Loa hospital or provider entity slug using the shared resolver. Use search_entities first if the slug is unknown. Results include provenance and explicit unavailable rows for requested CPT codes with no current price.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | Exact Loa entity slug from search_entities or a Loa SEO page. | |
| limit | No | Maximum number of prices, default 50, max 100. | |
| cpt_codes | No | Optional CPT codes to filter. If omitted, returns current indexed prices up to the limit. |
| Name | Required | Description |
|---|---|---|
| total | Yes | |
| entity | Yes | |
| prices | Yes | |
| loa_link | Yes | |
| provenance | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish that the operation is read-only, idempotent, and non-destructive. The description adds useful behavioral context beyond that: results are source-labeled, include provenance, and return explicit unavailable rows for requested CPT codes with no current price. This gives the agent realistic expectations about output behavior.
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?
Three sentences with no filler. The primary action is front-loaded, the prerequisite is stated immediately after, and the key behavioral guarantees are summarized in the final sentence. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only entity-price lookup with a rich input schema, an output schema, and safety annotations, the description covers the essential workflow: what is returned, how to handle an unknown slug, and what to expect in results. Nothing critical is missing for an agent to invoke it 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 coverage is 100%, so the schema already documents slug, limit, and cpt_codes. The description adds some behavioral nuance around 'requested CPT codes' and unavailable rows, but it does not materially extend parameter meaning beyond what the schema provides. 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?
The description clearly states the action ('Return source-labeled prices') and the target resource ('a Loa hospital or provider entity slug'). It distinguishes the tool from market-level or estimate tools by emphasizing entity-level, source-labeled prices, though it does not explicitly contrast with the similarly named get_hospital_pricing sibling.
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 gives explicit actionable guidance: 'Use search_entities first if the slug is unknown.' This tells the agent what to do when the required parameter may be unavailable. However, it does not discuss when to prefer this tool over alternatives like get_hospital_pricing or get_market_pricing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return one Loa hospital or provider entity profile by exact slug or entity_pages.id. Includes profile-field provenance so agents can distinguish source-file fields from Loa-reviewed overrides.
| Name | Required | Description | Default |
|---|---|---|---|
| slug_or_id | Yes | Exact Loa entity slug or entity_pages.id from search_entities. | |
| entity_type | No | Optional disambiguation when slug_or_id is a slug. |
| Name | Required | Description |
|---|---|---|
| entity | Yes | |
| loa_link | Yes | Tracked Loa link. Share it when the user wants to book, contact, or learn more about this provider or hospital. |
| provenance | Yes | |
| profile_provenance | Yes | |
| profile_field_provenance | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is well established. The description adds genuinely useful behavioral context by disclosing that the response includes profile-field provenance, letting agents distinguish source-file fields from Loa-reviewed overrides. No contradiction or hidden side effects are present.
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 with no filler: the first states the core behavior and the second adds a valuable distinguishing feature. The most decision-relevant information is front-loaded.
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, the annotations cover safety and idempotency, and the schema covers all parameters, the description provides everything an agent needs to select and invoke the tool correctly. It also adds the provenance detail that is not represented elsewhere.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents both parameters clearly, including the origin of slug_or_id from search_entities. The description essentially restates the lookup-key semantics without adding new format, usage, or interaction details beyond the schema.
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 ('Return') and names the exact resource ('one Loa hospital or provider entity profile') and lookup method ('by exact slug or entity_pages.id'). It clearly differentiates from sibling search tools by emphasizing a single exact-match profile rather than a list or pricing operation.
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 and parameter schema together make the use case clear: retrieve one entity when you already have its exact slug or entity_pages.id, often sourced from search_entities. It does not explicitly name sibling alternatives or state when not to use it, but the exact-match framing provides sufficient contextual guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Hospital-specific pricing tool for source-labeled Loa runtime data. Returns source-labeled Published MRF prices and Loa Verified Provider Price overlays for CPT codes. cash_price is the cash/self-pay price, list_price is the gross charge before discounts (most patients pay less), and insurance_prices are payer-negotiated rates for the named plan, not out-of-pocket costs. Any of these can be null when the hospital did not publish that price. Use this when comparing named hospitals or checking a quoted hospital price against available source rows.
| Name | Required | Description | Default |
|---|---|---|---|
| cpt_codes | Yes | CPT procedure codes to look up pricing for | |
| hospital_ids | Yes | Hospital IDs from search_hospitals results |
| Name | Required | Description |
|---|---|---|
| total | Yes | |
| pricing | Yes | |
| provenance | Yes | |
| services_found | Yes | |
| hospitals_found | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), and the description adds genuinely new behavioral context: that any price field can be null when unpublished and that insurance_prices are negotiated rates rather than out-of-pocket costs. This is meaningful interpretive guidance beyond the annotations, though return format/pagination is left to the output schema.
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?
It is front-loaded (purpose first, then field semantics, then usage) and every sentence carries information an agent needs, especially the null caveat. The middle field-glossary sentence is dense but earns its place by preventing misinterpretation of the price fields.
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 and annotations covering safety, the description need not restate return structure; it complements those by explaining field meaning, nullability, and intended use. It is complete enough to call correctly, missing only explicit sibling routing for non-hospital pricing queries.
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% for both parameters, so the schema already documents cpt_codes and hospital_ids (including array bounds and the search_hospitals provenance). The description adds no syntax, limits, or format detail beyond the schema, which is the expected baseline when schema coverage is complete.
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 resource (hospital pricing) and what it returns (source-labeled Published MRF prices plus Loa Verified Provider Price overlays for CPT codes), which distinguishes it from generic siblings like get_entity_prices and get_market_pricing. The internal jargon ('Loa runtime data', 'MRF') is opaque but the hospital scope is unmistakable.
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 gives an explicit when-to-use clause: 'comparing named hospitals or checking a quoted hospital price against available source rows.' It does not state when NOT to use it or name the sibling to prefer for market-level or estimate queries, so the routing is clear but not exhaustive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Preferred benchmark pricing tool. Returns hospital-level market statistics for CPT codes from Loa's published hospital price-transparency data: cash/self-pay prices, list prices (gross charges before discounts), overall insurer-negotiated rates, and rates for the most common insurers. Each hospital counts once. Lead with the median and the p25-p75 range rather than min or max. Figures are statewide or national, never local to a ZIP code. When status is insufficient_data, say Loa doesn't have enough data instead of estimating, and always relay the limitations. Negotiated rates are not out-of-pocket costs.
| Name | Required | Description | Default |
|---|---|---|---|
| state | No | State for regional pricing (e.g. "CA", "New York"). Unknown states return McpToolInvalidInput. When fewer than 5 hospitals in the state published a price, national figures are returned with a limitation. | |
| zip_code | No | ZIP code, used only to pick the state when state is omitted | |
| cpt_codes | Yes | CPT codes to look up (e.g. ["99213", "93000"]) |
| Name | Required | Description |
|---|---|---|
| state | Yes | |
| pricing | Yes | |
| provenance | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the read-only/idempotent safety profile, yet the description adds substantial non-obvious behavior: each hospital counts once, figures are statewide/national and never local to a ZIP, the insufficient_data status handling, and the caveat that negotiated rates are not out-of-pocket costs. This is exactly the behavioral context annotations cannot carry.
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 what the tool returns before the presentation caveats, and every sentence carries a directive. It runs slightly long with several distinct guidance clauses, but none are wasted.
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 no explanation, and the description adequately covers scope, the insufficient_data case, and interpretation pitfalls. The main remaining gap is that it never explicitly distinguishes itself from get_hospital_pricing/get_pricing_estimate for the agent.
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, but the description adds scope semantics: results are statewide or national and never local to a ZIP, reinforcing the state vs. zip_code relationship. It doesn't expand on cpt_codes beyond the schema's example.
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: it returns hospital-level market statistics (cash, list, and insurer-negotiated rates) for CPT codes, and calls itself the 'preferred benchmark pricing tool.' This differentiates it conceptually from siblings like get_hospital_pricing, though it never names an alternative explicitly.
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 clear context for use ('preferred benchmark pricing tool') and operational directives: lead with median and p25-p75 rather than min/max, and say data is insufficient rather than estimating. It does not, however, state when to prefer this over get_pricing_estimate or get_hospital_pricing, so tool-selection exclusion 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.
Quick cash-price ballpark for one or more CPT codes, using the median cash price across hospitals in the state (from zip_code) or nationally. priceRange is the typical range (25th to 75th percentile of hospitals). Codes without enough data return insufficient_data and are listed in missingCodes; the total is null unless every code has data. Never fill gaps with your own estimate. For insurer rates or hospital-specific prices, use get_market_pricing or get_hospital_pricing.
| Name | Required | Description | Default |
|---|---|---|---|
| zip_code | No | ZIP code used to pick the state (omit for national figures) | |
| procedure_codes | Yes | CPT procedure codes to price (e.g. ["99213", "85025"]) |
| Name | Required | Description |
|---|---|---|
| state | Yes | |
| zipCode | Yes | |
| disclaimer | Yes | |
| procedures | Yes | |
| provenance | Yes | |
| limitations | Yes | |
| missingCodes | Yes | |
| estimatedCost | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive, and the description adds substantive behavior: priceRange is the 25th-75th percentile band, codes with thin data return insufficient_data, they surface in missingCodes, total is null unless all codes have data, and the agent must not invent an estimate. That is far more than the safety hints the annotations provide.
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 sentences, each carrying distinct load: what it computes, what the output field means, how gaps are handled, and where to go for other price types. Front-loaded with the core purpose and tightly written with no filler.
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 is not obliged to explain returns, yet it clarifies the tricky semantics (percentile range, missingCodes, null total) that an agent would otherwise have to infer. Nothing needed to call this 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 100% and both parameters are already documented there, including the omit-for-national rule for zip_code. The description reinforces the state-from-zip semantics but adds no new format or constraint detail 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?
States a specific verb and resource ('cash-price ballpark for one or more CPT codes') plus the aggregation basis (median cash price across hospitals in-state or nationally), so the agent knows exactly what number it gets back. It explicitly names the sibling tools that serve different price types, making it distinguishable 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?
Explicit routing: 'For insurer rates or hospital-specific prices, use get_market_pricing or get_hospital_pricing,' and the schema/description together explain when to omit zip_code for national figures. Both the when-to-use and the when-to-use-something-else conditions are covered.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Canonical code-lookup tool for this server. Search Loa's CPT/HCPCS index using exact codes, clinical terms, or consumer phrases. Use this first when the user does not already know the CPT code, before calling pricing tools.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of results (default 10, max 25) | |
| query | Yes | Search query, procedure name, medical term, or CPT code number (e.g. "knee MRI", "blood work", "99213") | |
| category | No | Filter by category: "evaluation_management", "laboratory", "radiology", "surgery", "preventive" | |
| specialty | No | Filter by medical specialty (e.g. "cardiology", "dermatology") |
| Name | Required | Description |
|---|---|---|
| query | Yes | |
| total | Yes | |
| results | Yes | |
| category | Yes | |
| specialty | Yes | |
| provenance | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only and idempotent traits. The description adds the term 'canonical' and implies authoritative search behavior. No contradiction, but lacks details on edge cases (e.g., no results). Still sufficient given annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no wasted words. Front-loaded with the core purpose. Every sentence adds value: first defines identity, second provides usage context.
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 search tool with 4 fully described parameters, an output schema present, and no nested objects, the description is complete. It covers purpose, usage, and search modes without missing critical information.
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% with well-described parameters. The description adds value by explaining the search modes ('exact codes, clinical terms, or consumer phrases') and emphasizing it's the canonical tool, which is not in the schema.
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 verb ('search'), resource ('CPT/HCPCS index'), and scope ('canonical code-lookup tool'). It explicitly distinguishes from sibling pricing tools by positioning it as the first lookup.
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?
Explicit guidance: 'Use this first when the user does not already know the CPT code, before calling pricing tools.' This clearly defines when to use and hints at alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search Loa runtime hospital and provider entity pages by name or state. Use this before get_entity_prices when the user names a hospital or provider but does not know the exact Loa slug.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of results, default 20, max 50. | |
| query | No | Hospital or provider name to search for. | |
| state | No | Two-letter state code or full state name, e.g. CA or New York. | |
| entity_type | No | Optional filter for hospital or provider entities. |
| Name | Required | Description |
|---|---|---|
| query | Yes | |
| total | Yes | |
| entities | Yes | |
| provenance | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds context about querying by name/state and the slug prerequisite, but it does not disclose behaviors like partial matching, result ordering, or pagination beyond what the schema already provides.
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 concise sentences with no filler. The core search scope is front-loaded, followed by a clear usage recommendation. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With a full schema, an output schema, and safety annotations, the description covers the essential invocation context: what is searched, by what fields, and when it should be used. The main gap is not mentioning the closely related sibling search_hospitals and search_providers, which could affect tool selection.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the input schema fully documents all four parameters. The description loosely maps to query, state, and entity_type via 'by name or state' and 'hospital and provider', but it does not add meaningful semantics beyond the schema.
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 and resource: searching Loa runtime hospital and provider entity pages by name or state. It is clear about what the tool does, but it does not explicitly differentiate from sibling tools search_hospitals and search_providers, which cover overlapping scopes.
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 gives a specific, actionable use case: use before get_entity_prices when the user knows a hospital or provider name but not the exact Loa slug. However, it does not mention when to prefer search_hospitals or search_providers over this combined search tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search Loa's hospital directory by name or location and return hospital IDs plus address details. Use the returned hospital_ids with get_hospital_pricing to fetch source-labeled Published MRF and reviewed overlay prices.
| Name | Required | Description | Default |
|---|---|---|---|
| city | No | City name | |
| name | No | Hospital name to search for | |
| limit | No | Max results (default 20) | |
| state | No | Two-letter state code or full state name, e.g. "CA" or "New York". | |
| zip_code | No | ZIP code |
| Name | Required | Description |
|---|---|---|
| query | Yes | |
| total | Yes | |
| hospitals | Yes | |
| provenance | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already disclose that the tool is read-only, idempotent, and non-destructive. The description adds search scope and output context but does not disclose behavioral details like matching semantics, ordering, or rate limits. Adequate given the annotations, but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no filler. The first sentence front-loads the action, resource, and output; the second sentence adds valuable chaining context. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Between the fully documented parameters, the output schema, safety annotations, and the downstream chaining hint, the description is complete enough for an agent to select and invoke the tool correctly. 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?
All five parameters are fully documented in the input schema, so the schema carries the semantic weight. The description's phrase 'by name or location' summarizes the parameter categories but adds no detail beyond what the schema already provides.
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 the exact operation and resource: searching Loa's hospital directory by name or location. It also states the output (hospital IDs plus address details), which clearly differentiates it from provider or entity searches.
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 gives a concrete downstream workflow: use returned hospital_ids with get_hospital_pricing. However, it does not explicitly say when not to use this tool or compare it to search_providers/search_entities, so it falls just short of full alternative guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search public CMS NPI Registry data for clinicians and healthcare organizations by specialty, name, or location. Use returned provenance to understand the registry source and scope. Use this for provider lookup, not pricing.
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | Provider name to search for (e.g. "John Smith") | |
| limit | No | Max results (default 20) | |
| location | No | Location to search in | |
| specialty | No | Medical specialty (e.g. "Cardiology", "Family Medicine") |
| Name | Required | Description |
|---|---|---|
| query | Yes | |
| total | Yes | |
| providers | Yes | |
| provenance | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is covered. The description adds useful context about the public CMS NPI Registry source and instructs agents to use returned provenance, but it does not disclose operational details like rate limits or pagination behavior.
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 three short, purposeful sentences with no filler. It front-loads the core action and resource, then adds the provenance note and usage boundary efficiently.
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 lookup tool with rich schema coverage, annotations, and an output schema, the description covers the essential purpose, data source, and usage boundary. It could be slightly more complete by naming sibling alternatives, but nothing critical is missing for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters. The description mentions specialty, name, and location in prose but adds no new semantic detail beyond what the input schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Search public CMS NPI Registry data for clinicians and healthcare organizations by specialty, name, or location.' It is clearly distinct from pricing-related siblings and identifies the exact search dimensions, making the tool's purpose unambiguous.
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 'Use this for provider lookup, not pricing,' giving clear when-to-use and when-not-to-use guidance. However, it does not name a specific alternative tool for pricing or for other search types like search_entities or search_hospitals.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Submit a profile, listing, or price correction for Loa review without requiring a provider portal. This is the only mutating provider/entity tool. It requires OAuth, captures submitter and source evidence, records linked-provider status when available, and never changes public data until Loa approves the request.
| Name | Required | Description | Default |
|---|---|---|---|
| attestation | No | How the submitter is connected to the submitted evidence. | |
| entity_slug | No | Exact Loa entity slug if entity_page_id is not available. | |
| entity_type | No | Entity kind for the requested update; use unknown only when it cannot be determined. | unknown |
| price_items | No | Optional structured price rows proposed for Loa review. | |
| source_urls | No | Optional public URLs reviewers can use to verify the submitted change. | |
| request_type | Yes | Type of reviewed change being requested. | |
| source_notes | No | Short verification notes, source context, or callback instructions. | |
| entity_page_id | No | Loa entity_pages.id for the provider or hospital. | |
| submitter_name | No | Name of the person submitting the request. | |
| submitter_role | No | Submitter role, such as billing manager or authorized agent. | |
| idempotency_key | No | Optional stable retry key. Loa derives one from the payload if omitted. | |
| submitter_email | Yes | Work email for the submitting representative. | |
| submitter_phone | No | Optional callback phone number for reviewer follow-up. | |
| proposed_changes | No | Structured profile or listing fields proposed for Loa review. | |
| uploaded_file_url | No | Optional public URL for an uploaded evidence file. | |
| submitter_organization | No | Provider, hospital, or agent organization represented by the submitter. |
| Name | Required | Description |
|---|---|---|
| status | Yes | |
| requestId | Yes | |
| entityPageId | Yes | |
| reusedExisting | Yes | |
| updateRequestId | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description reveals that public data is never changed until Loa approval, aligns with non-destructive annotation, and adds details about capturing submitter/source evidence and linked-provider status, going beyond 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?
Three succinct sentences front-load the purpose, uniqueness, and key behaviors with no redundancy.
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 complex 16-parameter tool with nested objects and an output schema, the description covers mutability, auth, and workflow. Lacks error or result details, but output schema likely covers return values.
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% with descriptions for all parameters. The description adds no parameter-specific details beyond general behavioral context, so 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?
The description clearly states the tool submits profile, listing, or price corrections for review, and identifies itself as the only mutating provider/entity tool, distinguishing it from all read-only siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly states this is the only mutating tool, implying use for modifications, and mentions OAuth requirement. It implicitly differentiates from read-only siblings but lacks explicit when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Advisory helper that suggests likely CPT codes from a plain-English medical need. Uses Loa heuristics plus AI and is not authoritative or diagnostic. Use only when the user cannot name the procedure, then confirm candidates with search_cpt_codes before pricing them. Requires signing in to Loa; without sign-in, use search_cpt_codes with consumer phrases instead.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Natural language description of the medical need (e.g. "I have a rash on my arm", "need imaging for my lower back pain") |
| Name | Required | Description |
|---|---|---|
| type | Yes | |
| provenance | Yes | |
| interpretation | Yes | |
| suggestedCodes | Yes | |
| needsConfirmationWith | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, openWorld, idempotent, and non-destructive behavior. The description adds valuable context beyond those: it is 'not authoritative or diagnostic,' it 'uses Loa heuristics plus AI,' and it requires signing in to Loa. These traits materially affect how an agent should present results and handle auth, with no contradiction of 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?
Three sentences with zero waste: the core purpose is front-loaded, followed by the key caveat, then usage and alternative routing. Every sentence earns its place and no annotation facts are redundantly repeated.
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 single-parameter advisory tool with a full output schema and clear annotations, the description covers purpose, limitations, auth requirements, the follow-up confirmation step, and the no-sign-in fallback. Nothing an agent needs to invoke 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 coverage is 100%, so the schema fully documents the single query parameter with examples. The description reinforces the idea of a 'plain-English medical need,' but does not add syntax, format, or edge-case semantics beyond what the schema already provides. 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?
The description states a specific verb and resource: 'suggests likely CPT codes from a plain-English medical need.' It also differentiates itself from the sibling search_cpt_codes by explicitly limiting use to when 'the user cannot name the procedure,' so an agent can distinguish them without opening 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 gives explicit when-to-use ('Use only when the user cannot name the procedure'), a required follow-up action ('confirm candidates with search_cpt_codes before pricing them'), and a clear alternative for the unauthenticated case ('without sign-in, use search_cpt_codes with consumer phrases instead'). This is complete routing guidance.
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.
get_hospital_pricing2 fields changedOutput schema / properties / pricing / items / properties / list_priceAdded value: +{
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ]
+}Output schema / properties / pricing / items / requiredPrevious value: -[
- "hospital_id",
- "hospital_name",
- "hospital_location",
- "cpt_code",
- "cpt_description",
- "cash_price",
- "cash_source_labels",
- "insurance_prices",
- "source_labels",
- "record_count",
- "loa_link"
-]New value: +[
+ "hospital_id",
+ "hospital_name",
+ "hospital_location",
+ "cpt_code",
+ "cpt_description",
+ "cash_price",
+ "cash_source_labels",
+ "list_price",
+ "insurance_prices",
+ "source_labels",
+ "record_count",
+ "loa_link"
+]get_market_pricing12 fields changedInput schema / properties / state / descriptionPrevious value: -"State for regional pricing (e.g. \"CA\", \"New York\"). Unknown states return McpToolInvalidInput. Valid states with no regional data fall back to national averages."New value: +"State for regional pricing (e.g. \"CA\", \"New York\"). Unknown states return McpToolInvalidInput. When fewer than 5 hospitals in the state published a price, national figures are returned with a limitation."Input schema / properties / zip_code / descriptionPrevious value: -"ZIP code (used with state for location context)"New value: +"ZIP code, used only to pick the state when state is omitted"Output schema / properties / pricing / items / properties / cash_price / anyOfPrevious value: -[
- {
- "additionalProperties": false,
- "properties": {
- "average": {
- "type": "number"
- },
- "data_points": {
- "type": "number"
- },
- "max": {
- "type": "number"
- },
- "median": {
- "type": "number"
- },
- "min": {
- "type": "number"
- },
- "source": {
- "type": "string"
- }
- },
- "required": [
- "median",
- "average",
- "min",
- "max",
- "data_points",
- "source"
- ],
- "type": "object"
- },
- {
- "type": "null"
- }
-]New value: +[
+ {
+ "additionalProperties": false,
+ "properties": {
+ "average": {
+ "type": "number"
+ },
+ "data_points": {
+ "description": "Price records behind this figure",
+ "type": "number"
+ },
+ "hospital_count": {
+ "description": "Hospitals behind this figure; each counts once",
+ "type": "number"
+ },
+ "max": {
+ "type": "number"
+ },
+ "median": {
+ "type": "number"
+ },
+ "min": {
+ "type": "number"
+ },
+ "p25": {
+ "type": "number"
+ },
+ "p75": {
+ "type": "number"
+ },
+ "source": {
+ "enum": [
+ "state",
+ "national"
+ ],
+ "type": "string"
+ }
+ },
+ "required": [
+ "median",
+ "average",
+ "min",
+ "max",
+ "p25",
+ "p75",
+ "data_points",
+ "hospital_count",
+ "source"
+ ],
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+]Output schema / properties / pricing / items / properties / insurance_by_payerAdded value: +{
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "data_points": {
+ "type": "number"
+ },
+ "hospital_count": {
+ "type": "number"
+ },
+ "median": {
+ "type": "number"
+ },
+ "p25": {
+ "type": "number"
+ },
+ "p75": {
+ "type": "number"
+ },
+ "payer": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "payer",
+ "median",
+ "p25",
+ "p75",
+ "data_points",
+ "hospital_count"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+}Output schema / properties / pricing / items / properties / insurance_price / anyOfPrevious value: -[
- {
- "additionalProperties": false,
- "properties": {
- "average": {
- "type": "number"
- },
- "data_points": {
- "type": "number"
- },
- "max": {
- "type": "number"
- },
- "median": {
- "type": "number"
- },
- "min": {
- "type": "number"
- },
- "source": {
- "type": "string"
- }
- },
- "required": [
- "median",
- "average",
- "min",
- "max",
- "data_points",
- "source"
- ],
- "type": "object"
- },
- {
- "type": "null"
- }
-]New value: +[
+ {
+ "additionalProperties": false,
+ "properties": {
+ "average": {
+ "type": "number"
+ },
+ "data_points": {
+ "description": "Price records behind this figure",
+ "type": "number"
+ },
+ "hospital_count": {
+ "description": "Hospitals behind this figure; each counts once",
+ "type": "number"
+ },
+ "max": {
+ "type": "number"
+ },
+ "median": {
+ "type": "number"
+ },
+ "min": {
+ "type": "number"
+ },
+ "p25": {
+ "type": "number"
+ },
+ "p75": {
+ "type": "number"
+ },
+ "source": {
+ "enum": [
+ "state",
+ "national"
+ ],
+ "type": "string"
+ }
+ },
+ "required": [
+ "median",
+ "average",
+ "min",
+ "max",
+ "p25",
+ "p75",
+ "data_points",
+ "hospital_count",
+ "source"
+ ],
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+]Output schema / properties / pricing / items / properties / limitationsAdded value: +{
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+}Output schema / properties / pricing / items / properties / list_priceAdded value: +{
+ "anyOf": [
+ {
+ "additionalProperties": false,
+ "properties": {
+ "average": {
+ "type": "number"
+ },
+ "data_points": {
+ "description": "Price records behind this figure",
+ "type": "number"
+ },
+ "hospital_count": {
+ "description": "Hospitals behind this figure; each counts once",
+ "type": "number"
+ },
+ "max": {
+ "type": "number"
+ },
+ "median": {
+ "type": "number"
+ },
+ "min": {
+ "type": "number"
+ },
+ "p25": {
+ "type": "number"
+ },
+ "p75": {
+ "type": "number"
+ },
+ "source": {
+ "enum": [
+ "state",
+ "national"
+ ],
+ "type": "string"
+ }
+ },
+ "required": [
+ "median",
+ "average",
+ "min",
+ "max",
+ "p25",
+ "p75",
+ "data_points",
+ "hospital_count",
+ "source"
+ ],
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+ ]
+}Output schema / properties / pricing / items / properties / scopeAdded value: +{
+ "anyOf": [
+ {
+ "enum": [
+ "state",
+ "national"
+ ],
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+}Output schema / properties / pricing / items / properties / source_datesAdded value: +{
+ "anyOf": [
+ {
+ "additionalProperties": false,
+ "properties": {
+ "earliest": {
+ "type": "string"
+ },
+ "latest": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "earliest",
+ "latest"
+ ],
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "Extraction dates of the underlying hospital files (YYYY-MM-DD)"
+}Output schema / properties / pricing / items / properties / states_coveredAdded value: +{
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ]
+}Output schema / properties / pricing / items / properties / statusAdded value: +{
+ "enum": [
+ "ok",
+ "insufficient_data"
+ ],
+ "type": "string"
+}Output schema / properties / pricing / items / requiredPrevious value: -[
- "cpt_code",
- "cash_price",
- "insurance_price",
- "confidence",
- "cash_data_points",
- "insurance_data_points"
-]New value: +[
+ "cpt_code",
+ "status",
+ "scope",
+ "cash_price",
+ "list_price",
+ "insurance_price",
+ "insurance_by_payer",
+ "confidence",
+ "cash_data_points",
+ "insurance_data_points",
+ "states_covered",
+ "source_dates",
+ "limitations"
+]get_pricing_estimate21 fields changedInput schema / properties / zip_code / descriptionPrevious value: -"ZIP code for regional pricing (defaults to national average)"New value: +"ZIP code used to pick the state (omit for national figures)"Output schema / properties / containsHeuristicEstimatesRemoved value: -{
- "type": "boolean"
-}Output schema / properties / estimatedCost / anyOfAdded value: +[
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+]Output schema / properties / estimatedCost / typeRemoved value: -"number"Output schema / properties / limitationsAdded value: +{
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+}Output schema / properties / missingCodesAdded value: +{
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+}Output schema / properties / procedures / items / properties / estimatedCost / anyOfAdded value: +[
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+]Output schema / properties / procedures / items / properties / estimatedCost / typeRemoved value: -"number"Output schema / properties / procedures / items / properties / hospital_countAdded value: +{
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ]
+}Output schema / properties / procedures / items / properties / priceRange / additionalPropertiesRemoved value: -falseOutput schema / properties / procedures / items / properties / priceRange / anyOfAdded value: +[
+ {
+ "additionalProperties": false,
+ "properties": {
+ "max": {
+ "type": "number"
+ },
+ "min": {
+ "type": "number"
+ }
+ },
+ "required": [
+ "min",
+ "max"
+ ],
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+]Output schema / properties / procedures / items / properties / priceRange / propertiesRemoved value: -{
- "max": {
- "type": "number"
- },
- "min": {
- "type": "number"
- }
-}Output schema / properties / procedures / items / properties / priceRange / requiredRemoved value: -[
- "min",
- "max"
-]Output schema / properties / procedures / items / properties / priceRange / typeRemoved value: -"object"Output schema / properties / procedures / items / properties / pricingMethod / enumPrevious value: -[
- "observed_market_median",
- "heuristic_cpt_range"
-]New value: +[
+ "observed_market_median",
+ "insufficient_data"
+]Output schema / properties / procedures / items / properties / scopeAdded value: +{
+ "anyOf": [
+ {
+ "enum": [
+ "state",
+ "national"
+ ],
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+}Output schema / properties / procedures / items / requiredPrevious value: -[
- "code",
- "description",
- "estimatedCost",
- "priceRange",
- "pricingMethod",
- "data_points"
-]New value: +[
+ "code",
+ "description",
+ "estimatedCost",
+ "priceRange",
+ "pricingMethod",
+ "scope",
+ "data_points",
+ "hospital_count"
+]Output schema / properties / stateAdded value: +{
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+}Output schema / properties / zipCode / anyOfAdded value: +[
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+]Output schema / properties / zipCode / typeRemoved value: -"string"Output schema / requiredPrevious value: -[
- "estimatedCost",
- "procedures",
- "zipCode",
- "containsHeuristicEstimates",
- "provenance",
- "disclaimer"
-]New value: +[
+ "estimatedCost",
+ "procedures",
+ "zipCode",
+ "state",
+ "missingCodes",
+ "limitations",
+ "provenance",
+ "disclaimer"
+]get_entity_prices2 fields changedOutput schema / properties / loa_linkAdded value: +{
+ "anyOf": [
+ {
+ "additionalProperties": false,
+ "description": "Tracked Loa link. Share it when the user wants to book, contact, or learn more about this provider or hospital.",
+ "properties": {
+ "action": {
+ "enum": [
+ "book",
+ "website",
+ "profile"
+ ],
+ "type": "string"
+ },
+ "label": {
+ "type": "string"
+ },
+ "url": {
+ "format": "uri",
+ "type": "string"
+ }
+ },
+ "required": [
+ "url",
+ "action",
+ "label"
+ ],
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+ ]
+}Output schema / requiredPrevious value: -[
- "entity",
- "prices",
- "total",
- "provenance"
-]New value: +[
+ "entity",
+ "loa_link",
+ "prices",
+ "total",
+ "provenance"
+]get_entity_profile2 fields changedOutput schema / properties / loa_linkAdded value: +{
+ "additionalProperties": false,
+ "description": "Tracked Loa link. Share it when the user wants to book, contact, or learn more about this provider or hospital.",
+ "properties": {
+ "action": {
+ "enum": [
+ "book",
+ "website",
+ "profile"
+ ],
+ "type": "string"
+ },
+ "label": {
+ "type": "string"
+ },
+ "url": {
+ "format": "uri",
+ "type": "string"
+ }
+ },
+ "required": [
+ "url",
+ "action",
+ "label"
+ ],
+ "type": "object"
+}Output schema / requiredPrevious value: -[
- "entity",
- "profile_provenance",
- "profile_field_provenance",
- "provenance"
-]New value: +[
+ "entity",
+ "loa_link",
+ "profile_provenance",
+ "profile_field_provenance",
+ "provenance"
+]get_hospital_pricing2 fields changedOutput schema / properties / pricing / items / properties / loa_linkAdded value: +{
+ "anyOf": [
+ {
+ "additionalProperties": false,
+ "description": "Tracked Loa link. Share it when the user wants to book, contact, or learn more about this provider or hospital.",
+ "properties": {
+ "action": {
+ "enum": [
+ "book",
+ "website",
+ "profile"
+ ],
+ "type": "string"
+ },
+ "label": {
+ "type": "string"
+ },
+ "url": {
+ "format": "uri",
+ "type": "string"
+ }
+ },
+ "required": [
+ "url",
+ "action",
+ "label"
+ ],
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+ ]
+}Output schema / properties / pricing / items / requiredPrevious value: -[
- "hospital_id",
- "hospital_name",
- "hospital_location",
- "cpt_code",
- "cpt_description",
- "cash_price",
- "cash_source_labels",
- "insurance_prices",
- "source_labels",
- "record_count"
-]New value: +[
+ "hospital_id",
+ "hospital_name",
+ "hospital_location",
+ "cpt_code",
+ "cpt_description",
+ "cash_price",
+ "cash_source_labels",
+ "insurance_prices",
+ "source_labels",
+ "record_count",
+ "loa_link"
+]search_entities2 fields changedOutput schema / properties / entities / items / properties / loa_linkAdded value: +{
+ "anyOf": [
+ {
+ "additionalProperties": false,
+ "description": "Tracked Loa link. Share it when the user wants to book, contact, or learn more about this provider or hospital.",
+ "properties": {
+ "action": {
+ "enum": [
+ "book",
+ "website",
+ "profile"
+ ],
+ "type": "string"
+ },
+ "label": {
+ "type": "string"
+ },
+ "url": {
+ "format": "uri",
+ "type": "string"
+ }
+ },
+ "required": [
+ "url",
+ "action",
+ "label"
+ ],
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+ ]
+}Output schema / properties / entities / items / requiredPrevious value: -[
- "id",
- "entity_type",
- "slug",
- "canonical_name",
- "display_name",
- "city",
- "state",
- "zip_code",
- "data_quality_score",
- "updated_at"
-]New value: +[
+ "id",
+ "entity_type",
+ "slug",
+ "canonical_name",
+ "display_name",
+ "city",
+ "state",
+ "zip_code",
+ "data_quality_score",
+ "updated_at",
+ "loa_link"
+]search_hospitals2 fields changedOutput schema / properties / hospitals / items / properties / loa_linkAdded value: +{
+ "anyOf": [
+ {
+ "additionalProperties": false,
+ "description": "Tracked Loa link. Share it when the user wants to book, contact, or learn more about this provider or hospital.",
+ "properties": {
+ "action": {
+ "enum": [
+ "book",
+ "website",
+ "profile"
+ ],
+ "type": "string"
+ },
+ "label": {
+ "type": "string"
+ },
+ "url": {
+ "format": "uri",
+ "type": "string"
+ }
+ },
+ "required": [
+ "url",
+ "action",
+ "label"
+ ],
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+ ]
+}Output schema / properties / hospitals / items / requiredPrevious value: -[
- "hospital_id",
- "name",
- "address",
- "city",
- "state",
- "zip_code",
- "phone",
- "website"
-]New value: +[
+ "hospital_id",
+ "name",
+ "address",
+ "city",
+ "state",
+ "zip_code",
+ "phone",
+ "website",
+ "loa_link"
+]search_providers2 fields changedOutput schema / properties / providers / items / properties / loa_linkAdded value: +{
+ "anyOf": [
+ {
+ "additionalProperties": false,
+ "description": "Tracked Loa link. Share it when the user wants to book, contact, or learn more about this provider or hospital.",
+ "properties": {
+ "action": {
+ "enum": [
+ "book",
+ "website",
+ "profile"
+ ],
+ "type": "string"
+ },
+ "label": {
+ "type": "string"
+ },
+ "url": {
+ "format": "uri",
+ "type": "string"
+ }
+ },
+ "required": [
+ "url",
+ "action",
+ "label"
+ ],
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+ ]
+}Output schema / properties / providers / items / requiredPrevious value: -[
- "npi",
- "name",
- "specialty",
- "address",
- "city",
- "state",
- "zip_code",
- "phone"
-]New value: +[
+ "npi",
+ "name",
+ "specialty",
+ "address",
+ "city",
+ "state",
+ "zip_code",
+ "phone",
+ "loa_link"
+]submit_entity_update_request8 fields changedInput schema / properties / entity_type / descriptionAdded value: +"Entity kind for the requested update; use unknown only when it cannot be determined."Input schema / properties / price_items / descriptionAdded value: +"Optional structured price rows proposed for Loa review."Input schema / properties / proposed_changes / descriptionAdded value: +"Structured profile or listing fields proposed for Loa review."Input schema / properties / request_type / descriptionAdded value: +"Type of reviewed change being requested."Input schema / properties / submitter_name / descriptionAdded value: +"Name of the person submitting the request."Input schema / properties / submitter_phone / descriptionAdded value: +"Optional callback phone number for reviewer follow-up."Input schema / properties / submitter_role / descriptionAdded value: +"Submitter role, such as billing manager or authorized agent."Input schema / properties / uploaded_file_url / descriptionAdded value: +"Optional public URL for an uploaded evidence file."explain_price_sourcesget_entity_pricesget_entity_profileget_hospital_pricingget_market_pricingget_pricing_estimatesearch_cpt_codessearch_entitiessearch_hospitalssearch_providerssubmit_entity_update_requestsuggest_proceduresSearch US hospital prices, compare costs, and find insurance-negotiated rates.
CMS quality ratings, payer-negotiated prices, and clinician data for 41K+ US healthcare facilities.
Pay-per-call US healthcare data: hospital financials, prices, quality, exclusions, wages.
What US health plans pay for care: negotiated rates by plan, provider and billing code, near a ZIP.
Add one secure layer between your agents and this server.
