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

Annotations already declare readOnly, idempotent, non-destructive, and open-world, so the safety profile is covered. The description adds that the returned facts match lookup_nyc_building, which is useful consistency information, but says nothing about error behavior for a nonexistent id, rate limits, or result size.

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?

One efficient sentence with no filler, and the parameter guidance is packed into a tight parenthetical. Leading with a comparison to the sibling rather than the tool's own output slightly delays the core payload, but nothing is wasted.

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 must convey what comes back, and it does so only by reference to lookup_nyc_building rather than listing the facts returned. Combined with the 0% parameter coverage that the description partially compensates for, the definition is workable but leaves the agent dependent on the sibling tool's documentation for result contents.

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 0% and the schema only constrains the parameter to an integer >= 1, so the description carries the semantic load. It does so well by naming it the HPD building id and telling the agent exactly where to find that number (Woodpecker /b/ links, HPD Online), which is genuinely actionable detail absent from the schema.

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?

States a specific verb and resource: returns building facts for one building, keyed by HPD building id. It differentiates from the sibling lookup_nyc_building by scope ('for one building'), but the distinction is left implicit rather than spelled out, so the agent must infer how the two tools actually differ.

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 is only implied: having an HPD building id is the implied precondition, and the parenthetical about /b/ links and HPD Online helps the agent confirm it holds the right identifier. There is no explicit statement of when to choose this over lookup_nyc_building, nor any when-not guidance.

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