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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and non-destructive behavior, and the description does not contradict them. It adds value by specifying the return payload and the source dataset, which helps an agent anticipate output. It does not describe pagination behavior, but offset and limit are documented in the schema.

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?

Two sentences with roughly 20 words, front-loading the action and resource while every phrase contributes either scope or return information. There is no filler, no repetition of the schema, and no redundancy with annotations.

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 simple read-only search with fully documented optional parameters and no output schema, the description is nearly complete: it states the source, target entity type, and principal fields returned. It could explicitly mention pagination or default behavior, but the schema already provides defaults for limit and offset, so no critical invocation information is missing.

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%; all four parameters (limit, state, offset, name_contains) already have meaningful descriptions. The tool description adds no parameter-level meaning beyond what the schema provides, so the baseline of 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?

Description opens with a specific verb ('Search') and a concrete resource ('Medicare-certified nursing homes from CMS Nursing Home Compare'), and lists the returned fields including name, address, ownership, certification status, total beds, and quality measures. This clearly differentiates it from sibling tools such as cms_hospital_search or cms_home_health_search.

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 establishes clear context: this tool is for Medicare-certified nursing homes sourced from CMS Nursing Home Compare, so an agent searching for nursing home facilities can identify it. It does not explicitly name alternatives or state when not to use it, but the resource scope is unambiguous and the sibling tool names reinforce the distinction.

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