Skip to main content
Glama
cliwant

mcp-sam-gov

by cliwant

cms_facility_directory

Read-only

Search Medicare/Medicaid-certified healthcare facilities by type (nursing home, home health, hospice, dialysis) with filters for state and name. Returns facility details including address and ownership.

Instructions

Look up Medicare/Medicaid-certified healthcare FACILITIES by type — nursing homes, home health agencies, hospices, or dialysis facilities — with their name, address, city, state, zip, and ownership (CMS provider-data, keyless; data.cms.gov datastore-query API, four datasets). A healthcare-facility directory / market-map lane that generalizes cms_hospital_compare beyond hospitals. Input: facilityType (REQUIRED enum — 'nursing_home' ~14,695 / 'home_health' ~12,460 / 'hospice' ~6,852 / 'dialysis' ~7,490; selects the dataset id via a constant map, the value never enters the URL path), optional state (2-letter, EXACT), facilityName (a name fragment, case-insensitive substring/contains match against the dataset's primary-name column), size (1–100, default 25), offset. Returns { facilities:[{ name, address, city, state, zip, facilityType, ownership }] } + honest _meta. ★HONESTY: totalAvailable is the response's EXACT top-level count for the filter set, NEVER the returned-rows length; offset/size pagination (hasMore = offset+returned < count). name/address/ownership column names DIFFER across the four datasets, so each is COALESCED over per-dataset candidates (name: provider_name/facility_name/legal_business_name; address: address/provider_address/address_line_1; ownership: ownership_type/type_of_ownership/profit_or_nonprofit) — a field absent in the chosen dataset is null (unknown), NEVER an empty string and NEVER fabricated. facilityType is echoed on each row. A genuine no-match ⇒ honest empty (returned:0); an invalid facilityType ⇒ invalid_input (blocked by the enum); 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 facility directory, NOT a clinical-quality or fitness determination. KEYLESS — no key is sent.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
sizeNoMax facility rows to return (1–100, default 25). Offset-paginated.
stateNoAn optional 2-letter US state/territory code (→ state, EXACT match), e.g. 'VA', 'TX'. Validated ^[A-Za-z]{2}$.
offsetNoRow offset for pagination (default 0). Page with _meta.pagination.nextOffset.
facilityNameNoAn optional facility-name fragment (case-insensitive SUBSTRING/contains match against the dataset's primary-name column). Allowed: letters/digits/space/& . , ( ) / ' - (≤100 chars).
facilityTypeYesREQUIRED — which CMS provider-data dataset to search: 'nursing_home' (~14,695), 'home_health' (~12,460), 'hospice' (~6,852), or 'dialysis' (~7,490). Selects the dataset id via a constant map (the value never enters the URL path).
Behavior5/5

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

Annotations already declare readOnlyHint=true and openWorldHint=true. The description adds extensive behavioral details: honest pagination with totalAvailable from count, coalescing of column names across four datasets, handling of missing fields (null, never empty string), error responses (no-match → empty, invalid input → invalid_input, 4xx/5xx behavior), server-side AND filtering, and keyless access. No contradiction with annotations.

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

Conciseness3/5

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

The description is quite verbose (multiple paragraphs with technical details like URL path behavior and column coalescing). While well-structured and front-loaded with core purpose, it could be more concise for quick scanning. Every sentence adds value, but length may hinder readability.

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 (multi-dataset, pagination, coalescing), the description is remarkably complete. It covers return format, honest pagination, error handling, field behavior, and keyless access. No output schema exists, so the description compensates fully.

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?

Schema coverage is 100%, baseline 3. The description adds value beyond schema: provides counts for each facilityType enum, explains that the value selects a dataset id via constant map, describes state validation regex, and clarifies facilityName as case-insensitive substring match. This enhances parameter understanding.

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's purpose: to look up Medicare/Medicaid-certified healthcare facilities by type, returning name, address, city, state, zip, and ownership. It distinguishes itself from siblings by noting it generalizes cms_hospital_compare beyond hospitals.

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 input requirements (facilityType required, optional state, facilityName, size, offset) and states that it is a facility directory, not a clinical-quality tool. It hints at alternatives by mentioning it generalizes cms_hospital_compare, but does not explicitly contrast with sibling tools like nppes_lookup_provider.

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