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

Annotations already cover the safety profile (readOnly/idempotent/non-destructive), and the description goes well beyond them: it discloses real coverage numbers (2,294 of 2,851 with source text, 258 mentioning structure type, 0% for pre-2020 completed complexes), that coverage is emitted on every response, that missing values return 'unknown' which is not a negative, and that the agent should route to how_to_find_out rather than dead-end.

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 purpose is front-loaded in the first sentence, but the body is heavy: bolding, scare-quoted questions, repeated framing of the 'two false common beliefs', and coverage statistics restated across paragraphs. Much of the content earns its place, yet the same points are made more than once and the layout is denser than needed.

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?

There is no output schema, so the description takes on that burden and does so thoroughly: it describes the two response layers (100% normative vs sparse complex-level), how coverage is reported per response, and the presence of a how_to_find_out field for the unknown case. An agent has everything needed to interpret results.

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% and the enum for axis is already documented in the schema, so the schema carries the parameter burden. The description reinforces that complex_name is optional and what happens when it is omitted, but adds no syntax or format detail beyond what the schema already states. 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?

States a specific decision it enables (whether an apartment's walls and plumbing can be altered) split into two explicit axes, ①load-bearing wall removal ②plumbing/stack relocation. It names the sibling that holds the full statutory text (realty_policy_rules(topic='unit_alteration_rules')), so an agent can tell the two apart without opening either schema.

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?

Gives concrete trigger questions ("can I move the bathroom?", "do I need a district office permit?") and spells out the conditional behavior: leave complex_name empty to get the normative layer alone, supply it for complex-level notice citations. It routes to a named alternative for the full statute text, though it never states a clear when-not-to-use condition.

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