Cash-pay MRI prices at 5,419 US hospitals.
Scored across 6 tools
Each tool targets a distinct resource and action: single listing retrieval by slug, full-text search, stats, and three independent list operations for categories, places, and sources. No overlapping purposes exist; the descriptions clearly differentiate slug-based get from query-based search.
All tool names follow a consistent snake_case verb_noun pattern with predictable verbs (get_, list_, search_). There are no deviations or mixed conventions across the six tools.
Six tools is well-scoped for a read-only data API covering listings, stats, categories, places, sources, and search. Each tool earns its place without redundancy or obvious omission.
Core read operations are covered, but there is no explicit tool to list all hospitals or retrieve individual category/place/source details. Search can partially fill the gap, yet a direct list endpoint is missing for full browseability.
Get one published hospital by its slug.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | The listing slug. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds one genuine behavioral fact beyond that — only *published* listings are retrievable — but says nothing about what happens for unknown or unpublished slugs (empty result vs error).
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?
A single eight-word sentence with the verb, scope qualifier ("published") and lookup key front-loaded. Nothing is padded or redundant.
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 one-parameter read tool with full annotations and no output schema, this is nearly sufficient. The only missing piece an agent might want is failure semantics for a nonexistent or unpublished slug.
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?
Only one parameter, and the schema fully documents it (100% coverage) with type, pattern and length constraints. The description's "by its slug" merely restates the parameter's role, adding no format or sourcing guidance, so the baseline 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?
Specific verb+resource: retrieves exactly one published hospital identified by slug, which is clearly distinct from the bulk-oriented search_listings and list_* siblings. It never names those siblings explicitly, but the singular "one ... by its slug" framing makes the single-item contract obvious.
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?
Usage is implied rather than stated: an agent can infer it should call this when it already holds a slug and wants the full record for one listing. There is no explicit when-not guidance (e.g., "use search_listings when you don't have a slug") and no prerequisites or fallback behavior mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the number of published hospitals, places and categories, and when the data last changed.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and a closed world, so the safety profile is fully covered. The description usefully adds the data scope ('published' only) and that a last-changed timestamp is included, but says nothing about caching, rate limits or refresh behavior for that timestamp.
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?
One sentence, no filler, and the entity list plus the freshness clause are front-loaded. Nothing in the sentence could be dropped without losing information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no input parameters and no output schema, the description carries the burden of explaining return values, and it does so precisely: counts of published hospitals, places and categories plus the last-changed date. An agent can call this correctly with no further 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?
The tool takes zero parameters, so there is no parameter semantics to document; baseline is 4. The description correctly implies the result is unfiltered global counts rather than something scoped by arguments.
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 resource (counts of published hospitals, places and categories) plus a freshness datum (last change time). That content profile implicitly separates it from the list_*/search_* siblings, which return items rather than counts, though no sibling is named 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?
The description never says when to reach for this tool instead of get_listing, list_categories, list_places or search_listings. The use case (aggregate overview vs. item retrieval) is only inferable from the return content.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List categories with their hospital counts.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and a closed world, so the safety profile is fully covered elsewhere. The description's only added context is that results include hospital counts, which is useful given there is no output schema, but it says nothing about ordering, pagination, or what a category record contains.
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?
A single eight-word sentence with the resource front-loaded and the payload detail trailing. Nothing is padded or redundant.
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 parameterless, read-only list tool with full annotation coverage and no output schema, the description supplies exactly the missing piece: what the returned items carry (hospital counts). Nothing an agent needs in order to call it correctly is absent.
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?
The tool takes zero parameters, and the schema still reports 100% coverage, so there is no parameter semantics to document. Baseline for a no-parameter tool 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 ('List categories') and adds that each entry carries a hospital count, so an agent knows both the operation and the shape of the result. It does not, however, differentiate itself from siblings like list_places or list_sources, which use near-identical 'list + noun' phrasing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to reach for this tool versus list_places, list_sources, or get_stats, nor any stated precondition. The agent must infer usage purely from the name and the mention of hospital counts.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List countries, regions and cities that have hospitals.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered. The description does add one genuinely useful behavioral fact — the list is a derived subset (only places that have hospitals), not a complete geography — but says nothing about ordering, return shape, or whether results are cached/static.
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?
A single front-loaded sentence with no filler. The resource and its scoping constraint are both stated immediately.
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 no output schema, the description is the only place an agent could learn the return shape — whether results are flat strings, hierarchical country/region/city objects, or include codes — and it does not say. For a zero-param list tool this is adequate but leaves the return format undefined.
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?
The tool takes zero parameters, so the schema-baseline of 4 applies. The description adds nothing on parameters, but there is nothing to add — invocation requires no arguments.
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 ('List') plus a precisely scoped resource ('countries, regions and cities that have hospitals'). The hospital-derived scope distinguishes it clearly from sibling listers such as list_categories and list_sources without needing to open 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?
Usage is only implied: an agent can infer this is the lookup for valid geographic filter values, since the returned set is constrained to places with hospitals. There is no explicit statement of when to use this versus search_listings or get_listing, and no exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List where the hospital data comes from, with the license and refresh of each source.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and a closed-world scope, so the safety profile is fully covered. The description adds the useful detail that each entry carries license and refresh information, but says nothing about result size, pagination, or ordering.
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?
One sentence, front-loaded with the action and resource, and the returned fields are appended compactly. No filler or 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 zero-parameter read-only listing with no output schema, the description supplies the key return-shape information (license and refresh per source). It is nearly complete, with only result volume and ordering left unstated, which are minor for a fixed enumeration.
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?
The tool takes zero parameters, which is the baseline-4 case regardless of the 100% schema coverage. The description correctly implies no filtering or selection input is 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?
Specific verb (list) plus a concrete resource (data sources), and it names the fields surfaced (license, refresh), so an agent knows this is provenance metadata rather than raw data. It does not explicitly contrast itself with siblings like get_stats, but the resource is distinctive enough to be 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?
There is no when-to-use guidance: nothing says whether this is for citation/licensing checks, freshness audits, or provenance display, and no sibling is named as an alternative. Usage can only be inferred from the noun 'sources'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search published hospitals by text, place and category.
| Name | Required | Description | Default |
|---|---|---|---|
| q | No | Search text, with at least one letter or digit. Matches name, categories, attributes, description and place. Typos fall back to close matches. | |
| city | No | City slug, from /places. | |
| sort | No | `relevance` needs `q` and is the default with it. `name` is the default without `q`. `recent` is newest first. | |
| limit | No | Items per page. | |
| cursor | No | `page.nextCursor` from the previous response. Opaque. Send the same filters and `limit`. | |
| region | No | Region slug, from /places. | |
| country | No | ISO 3166-1 alpha-2 country code, any case. A country the directory does not cover, as listed in /places, gives 400. | |
| category | No | Category slug, from /categories. A parent slug also matches its children. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is fully covered. The description adds only the 'published' scope qualifier, which is meaningful but thin; it says nothing about result shape or how matching/fuzzy behavior works despite the schema hinting at close-match fallback.
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?
A single sentence with no filler, and the core action is front-loaded. It is efficient, though its brevity for an eight-parameter search tool borders on under-specification rather than true 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?
With params fully documented and safety covered by annotations, no output schema is strictly required. However, the description omits what the results actually contain, the existence of pagination via cursor, and the fact that unpublished listings are excluded, which leaves an agent with an incomplete picture of a fairly rich search surface.
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 all eight parameters are already documented in detail, including slugs, defaults, enum semantics and cursor pagination. The description's 'text, place and category' grouping adds only a light thematic mapping over what the schema already states, which is the expected baseline 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb and resource ('Search published hospitals') and scopes it to three axes (text, place, category), which clearly separates it from siblings like get_listing and list_places. It stops short of explicitly naming or contrasting any alternative, so it is clear but not fully differentiating.
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 when-to-use or when-not-to-use guidance is offered. The word 'published' implies a scope restriction, but the description never states the condition that selects this tool over get_listing, or that unpublished entries are excluded, leaving routing entirely to inference.
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_listingget_statslist_categorieslist_placeslist_sourcessearch_listingshospital-prices -- what US hospitals charge for a service: gross charge, self-pay price and…
Search US hospital prices, compare costs, and find insurance-negotiated rates.
What US health plans pay for care: negotiated rates by plan, provider and billing code, near a ZIP.
US drug price benchmarks — what a pharmacy PAYS and what Medicare PAYS OUT.
Add one secure layer between your agents and this server.
