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

Even with readOnlyHint=true, the description adds substantial behavioral context: it requires an Authorization key, summarizes the return payload (per-verdict counts, most severe items, verbatim caveat, source and read date), and honestly discloses the no-machine-readable-chart edge case. This goes well beyond the annotation.

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 three focused sentences: the core action, the auth prerequisite, and the return/edge-case behavior. It front-loads the main purpose and every sentence adds useful information without waste.

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?

Given no output schema, the description appropriately explains what the tool returns: per-verdict counts, severe items, the cross-contact caveat, and chart metadata. It also covers the no-chart case, auth requirements, and the relationship to the register sibling, making the tool usable without further guessing.

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?

The schema already documents restrictions thoroughly, including FDA-9 keys and the optional note object. The description references 'household restrictions' and 'venue's published chart,' but it does not add meaningful syntax or format details beyond what the schema provides, and the venue parameter itself lacks descriptive compensation.

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 uses a specific verb-resource pairing: 'Rule a whole venue's published chart against the household restrictions in one call.' This clearly distinguishes the tool from siblings like check_item and check_plan by emphasizing whole-venue scope and single-call behavior.

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 gives clear context for when to use the tool: when you want to assess an entire venue's chart rather than individual items or plans. It also states the prerequisite of a Bearer key and points to the register tool for obtaining one, though it does not explicitly name when to prefer check_item or check_plan.

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