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

Annotations already flag read-only, open-world, idempotent, and non-destructive behavior, but the description goes much further: it reveals that coverage may be only 11.2% or 0%, that unknown is not a negative answer, that structure should not be inferred from the year of construction, and that responses must include how_to_find_out. This is substantial value beyond the annotations and no contradiction is found.

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 core purpose and uses bold headers and two clear 'layer' sections to structure a domain-heavy signal. It is long, but almost every passage carries a specific warning or facility distinction that is needed for this recalcitrant task. The main cost is density, not irrelevance.

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, but the description states the two expected response layers, coverage disclosure requirement, unknown handling, and how_to_find_out path, so the sentiment model knows what to expect and how to behave. It does not formally specify response field names or error cases, but for an open-world read-only tool this is sufficient.

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 input schema already documents all three parameters well, including enum values, null defaults, and the meaning of omitting the complex name. The description explains only the general behavior of the 'unknown' case and response structure, but it does not add new semantic information about individual parameters beyond what the schema provides. Since schema_description_coverage is 100%, baseline 3 is appropriate.

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 clearly states the tool's job: it answers whether walls can be demolished and plumbing/bathrooms moved, using statute text and the original public-sale notice. It explicitly distinguishes itself from realty_policy_rules by noting the full norm text lives there, which helps an agent select the right sibling.

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 concrete example queries that map to this tool, explains that the normative layer works even without a complex name, and points to realty_policy_rules as the source of the full rule text. It is less clear about when not to use this tool in favor of adjacent realty_* tools, but the axis,building-name, and coverage logic supplies usable routing context.

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