Skip to main content
Glama
cliwant

mcp-sam-gov

cms_facility_directory

Read-only

Find Medicare/Medicaid-certified healthcare facilities by type, state, or name. Search nursing homes, home health agencies, hospices, and dialysis providers to get addresses and ownership details.

Instructions

Medicare/Medicaid-certified healthcare facilities by type — nursing homes, home health agencies, hospices, or dialysis facilities — with name, address, city, state, zip, and ownership (CMS provider-data, keyless; data.cms.gov datastore-query API, four datasets). 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 (case-insensitive substring), size (1–100, def 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; hasMore = offset+returned < count. name/address/ownership column names DIFFER across the four datasets → 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 (NEVER an empty string, NEVER fabricated). facilityType is echoed on each row. Filters applied SERVER-SIDE (AND-combined) — nothing silently dropped. Genuine no-match → honest empty; invalid facilityType → invalid_input (enum-blocked); 4xx → invalid_input/not_found; 5xx → THROWS; 200 non-array or missing count/results → schema_drift. NOT a clinical-quality or fitness determination.

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).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.12.0

TDQS

A4.6/5.0
Behavior5/5

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

The description goes far beyond the readOnlyHint/openWorldHint annotations: it documents exact count semantics for totalAvailable, the hasMore formula, per-dataset column coalescing, null-never-empty behavior, server-side AND filters, and precise error mapping (invalid_input, not_found, schema_drift, throws on 5xx). This gives an agent an unusually honest model of the tool's behavior.

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 long but tightly structured: purpose, inputs, return shape, honesty guarantees, error behavior, and caveat. It front-loads the core purpose and uses compact notation. A small amount of parameter detail repeats the input-schema descriptions, but almost every sentence carries operational value.

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?

With no output schema and only minimal annotations, the description carries the full burden of explaining return values and edge cases. It specifies the exact response shape ({ facilities: [...] } plus _meta), pagination, coalescing rules, absent-field behavior, and failure semantics. An agent has everything needed to call this tool and interpret its results correctly.

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%, so the baseline is 3, but the description adds meaningful parameter nuance: facilityType selects a dataset via a constant map and never enters the URL path, approximate row counts per enum value are provided, and filter semantics (EXACT state, case-insensitive substring facilityName) are reinforced. It does not fully duplicate the schema and adds operational meaning.

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 opens with a specific verb and resource: 'Medicare/Medicaid-certified healthcare facilities by type' and enumerates the four facility types and returned fields. It distinguishes itself from broader CMS/socrata siblings by emphasizing the keyless datastore-query API and the four fixed datasets. The closing 'NOT a clinical-quality or fitness determination' further sharpens its scope.

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 tool is clearly scoped for searching four named CMS provider datasets by facility type, and the description explicitly states what it is not for ('NOT a clinical-quality or fitness determination'). However, it does not name specific sibling alternatives or give explicit when-to-use-this-vs-that routing, so it falls short of the highest bar.

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

Deploy Server

Other Tools