apibase

CMS — US Nursing Home Search

cms.nursing_home.search

Read-onlyIdempotent

Search 14 600+ Medicare/Medicaid-certified nursing homes and long-term care facilities in the US with CMS 5-star quality ratings. Filter by state, city, ZIP code, name, minimum overall rating, and ownership type (for-profit, non-profit, government). Returns CMS Certification Number (CCN), provider name, address, phone, ownership, certified bed count, and four separate quality ratings: overall (1–5 stars), health inspection, staffing, and quality measures. Star ratings help families compare nursing homes objectively for long-term care placement. No auth — US Centers for Medicare & Medicaid Services public domain, unlimited free.

Input Schema

TableJSON Schema

Name	Required	Description
`city`	No	City or town name to filter nursing homes (partial match). Example: "Miami", "Chicago".
`name`	No	Partial nursing home name to search (case-insensitive substring match). Example: "Sunrise", "Brookdale", "Manor".
`limit`	No	Maximum number of nursing homes to return (1–100, default 20).
`state`	No	Two-letter US state abbreviation to filter nursing homes (e.g. FL, CA, TX).
`offset`	No	Number of results to skip for pagination (default 0).
`zip_code`	No	5-digit US ZIP code to filter nursing homes by location.
`min_rating`	No	Minimum CMS Overall Star Rating (1–5 stars). Higher ratings indicate better quality of care based on health inspections, staffing levels, and quality measures.
`ownership_type`	No	Filter by ownership type. Common values: "For profit - Corporation", "Non profit - Corporation", "Government - State", "Government - County", "For profit - Individual".

Output Schema

TableJSON Schema

Name	Required	Description	Default
`error`	No	Present only when the call failed. Includes error code, message, request_id, and any provider-specific extras.
`result`	No	Tool response payload. Shape varies per tool — consult the tool description and inputSchema. May be an object, array, string, or number depending on the upstream provider response.

Schema Changelog

Changes observed during successful MCP inspections.

First observedSep 22, 2026

TDQS

A4.3/5.0

Behavior4/5

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

Annotations already establish read-only, idempotent, non-destructive behavior. The description adds valuable context beyond that: no authentication required, public-domain data, unlimited free usage, and the specific quality-rating fields returned. It does not contradict any annotation.

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

Conciseness5/5

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

The description is appropriately sized and front-loaded: the first sentence states the core action and scope, followed by filters, outputs, and a usage note. Every sentence carries useful information without redundancy.

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?

Combined with the rich input schema and the presence of an output schema, the description covers the essential context: data source, scope, filters, returned fields, rating scale, and authentication/usage caveats. Nothing critical is missing for an agent to select and invoke this tool correctly.

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

Parameters3/5

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

Schema coverage is 100%, so the parameters are already well documented. The description paraphrases the filter dimensions (state, city, ZIP, name, minimum rating, ownership type) but adds no semantic detail beyond what the schema provides.

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 ('Search') and a clearly bounded resource: Medicare/Medicaid-certified nursing homes and long-term care facilities in the US. It also names the key differentiation (CMS 5-star quality ratings), which distinguishes it from sibling CMS tools like cms.hospital.search and cms.dialysis.search.

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 gives clear context for when this tool is useful—comparing nursing homes for long-term care placement using star ratings. It does not explicitly state exclusions or name alternatives, but the scope is obvious enough that an agent can infer when to choose it over CMS sibling tools.

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

All apibase tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.