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

Annotations only declare readOnlyHint and openWorldHint; the description adds genuinely useful behavior: a hard cap of 50 hospitals per state per call, the $0.002 x402 charge per successful call with failures not billed, and the caveat that the star rating exists only 'when CMS publishes one.' It leaves one meaningful hole: with a 50-per-state ceiling, there's no indication of how (or whether) an agent can retrieve results beyond that cap.

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?

The description is front-loaded with the data contents, then alternatives, then pricing, which is a sensible order. The 'Choose this tool for: CMS Hospital General Information: hospital name, city' sentence is pure repetition of the title and first clause and could be dropped without losing information.

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?

With an output schema present, the description needn't explain return shapes, and annotations cover the read-only profile; what remains is cost, result caps, and sibling routing, all of which are stated. The only real gap is the absence of any guidance on exceeding the 50-record ceiling, which matters for a state with many hospitals.

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 coverage is 100%, so both `state` (two-letter code, example VT) and `max` are already documented in the schema. The description only indirectly reinforces the 1-50 range via 'Up to 50 records per state per call' and adds nothing about the string type of `max` or default behavior. Baseline 3 applies when the schema carries the parameter semantics.

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?

The opening sentence names the source (data.cms.gov) and enumerates exactly what the tool returns: name, city, type, ownership, emergency services, overall star rating, and better/no-different/worse measure counts. That is far more specific than the title alone. It loses a point because the 'Choose this tool for:' clause just restates the title verbatim rather than sharpening the purpose.

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?

It explicitly names two close alternatives on the server (health_cms_medicare_part_d and health_medicare_advantage_star) and summarizes what each covers, so an agent can route between them without opening schemas. It stops short of stating when NOT to use this tool or how it relates to adjacent hospital datasets like health_physician_compare_cms or health_medicare_inpatient_drg.

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