Skip to main content
Glama
cliwant

mcp-sam-gov

by cliwant

cms_hospital_compare

Read-only

Retrieve Medicare-certified hospital information by US state or facility name. Access location, type, ownership, emergency services, and CMS star rating from CMS Hospital Compare data.

Instructions

Look up Medicare-certified hospitals by US state and/or facility-name fragment — location, type, ownership, emergency-services flag, and CMS star rating (CMS Hospital Compare 'Hospital General Information', keyless; data.cms.gov provider-data datastore-query API, ~5,432 hospitals). A healthcare-facility directory / market-map lane (WHERE hospitals are and HOW CMS rates them). Input: state (2-letter, EXACT) OR facilityName (a name fragment, case-insensitive substring/contains match) — at least ONE is REQUIRED (an all-empty query is refused; hospitalType alone is NOT enough to scope); optional hospitalType (substring, e.g. 'Acute', 'Critical Access'), size (1–100, default 25), offset. Returns { hospitals:[{ facilityId, facilityName, address, city, state, zip, county, phone, hospitalType, ownership, emergencyServices, overallRating }] } + honest _meta. ★HONESTY: totalAvailable is the response's EXACT top-level count for the filter set (VA=96), NEVER the returned-rows length; offset/size pagination (hasMore = offset+returned < count). overallRating is CMS's 1–5 star rating as a number; 'Not Available'/blank/non-numeric ⇒ null (NEVER 0). emergencyServices normalizes 'Yes'⇒true / 'No'⇒false / else null (never a fabricated false). IDs/names/addresses are null-never-empty-string. A genuine no-match ⇒ honest empty (returned:0); a 4xx ⇒ invalid_input/not_found; a 5xx ⇒ THROWS; a 200 non-array body or one missing count/results ⇒ schema_drift. Filters are applied SERVER-SIDE (AND-combined) — nothing is silently dropped. This is a summary star rating, NOT a clinical-quality or fitness determination. KEYLESS — no key is sent.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
sizeNoMax hospital rows to return (1–100, default 25). Offset-paginated.
stateNoA 2-letter US state/territory code (→ state, EXACT match), e.g. 'VA', 'CA'. Provide at least this OR `facilityName`. Validated ^[A-Za-z]{2}$.
offsetNoRow offset for pagination (default 0). Page with _meta.pagination.nextOffset.
facilityNameNoA hospital-name fragment (→ facility_name, case-insensitive SUBSTRING/contains match), e.g. 'children'. Provide at least this OR `state`. Allowed: letters/digits/space/& . , ( ) / ' - (≤100 chars).
hospitalTypeNoAn optional hospital-type filter (→ hospital_type, case-insensitive SUBSTRING/contains match), e.g. 'Acute', 'Critical Access'. Allowed: letters/digits/space/& . , ( ) / ' - (≤100 chars).
Behavior5/5

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

The description disclosed all behavioral traits: pagination with honest count, null handling for ratings and emergency services, error handling (4xx, 5xx, schema drift), server-side filtering, and keyless operation. Annotations only provide readOnlyHint and openWorldHint; the description goes far beyond with concrete details.

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

Conciseness4/5

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

The description is lengthy but well-structured: a concise opening sentence, followed by parameter details, return format, honest behaviors, and error handling. It is front-loaded with the core purpose and uses bullet-like formatting for clarity. While it could be slightly trimmed, every sentence adds necessary detail for a complex tool.

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

Completeness5/5

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

Given the tool's complexity (5 parameters, no output schema but return details described, pagination, null handling), the description is remarkably complete. It covers input constraints, output structure, edge cases, and error conditions, leaving no gap for an agent to misinterpret usage. The absence of an output schema is fully compensated.

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

Parameters4/5

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

The input schema already describes all five parameters with detailed descriptions, achieving 100% coverage. The description adds value by clarifying match semantics (EXACT vs. substring), allowed characters, validation rules, and default values, enhancing agent understanding beyond the schema.

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

Purpose5/5

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

The description clearly states the tool looks up Medicare-certified hospitals by state and/or facility name, detailing the specific fields returned (location, type, ownership, emergency services, star rating). It defines the resource and action precisely, and the scope is well-delineated, making it distinct from sibling CMS tools.

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

Usage Guidelines4/5

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

The description provides explicit constraints: at least one of state or facilityName is required, hospitalType alone is insufficient, and pagination parameters are specified. It does not directly state when not to use the tool or list alternatives, but the constraints are clear enough for effective selection.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/cliwant/mcp-sam-gov'

If you have feedback or need assistance with the MCP directory API, please join our Discord server