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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, openWorld). The description goes beyond them by disclosing the return contents (Medicare ownership classification, city, phone) and an important domain rule ("Nonprofit hospitals must have a financial assistance policy"), which is genuinely useful behavioral context. It doesn't discuss rate limits or match ambiguity.

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?

Front-loaded with purpose, then examples, then return contents, in a logical order. It is a touch redundant, restating the title's phrase "whether a hospital is nonprofit, for financial assistance" at the start, but the sentences otherwise earn their place.

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 no output schema, the description carries return-value disclosure and does so adequately, listing ownership classification, city, phone number, and the financial-assistance implication. It stops short of describing behavior when multiple hospitals match, though the city/state params imply that handling.

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%, so each parameter (name, city, state) is already well documented in the schema. The description adds no parameter-level syntax or disambiguation guidance beyond hinting that ownership results are location-aware, so the baseline 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?

The description states a precise transactional purpose: looking up whether a hospital is nonprofit to determine eligibility for financial assistance. It grounds this with concrete example questions ("is St. Luke's in Boise a nonprofit?"), which makes the resource and scope unmistakable and naturally distinct from medbillcheck siblings that handle prices, whole bills, or letters.

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?

Usage context is clear via the example user requests, which effectively communicate when to reach for this tool. However, no alternative tools are named and no exclusions are given, so an agent must infer the boundary against siblings like check_price or check_whole_bill on its own.

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