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

With no annotations, the description must carry the behavioral burden, and it does convey useful traits: a bounded result set ('top 25') and that entries come with remediation steps. 'Retrieve' implies a read-only operation. However, it says nothing about whether the count is a hard cap when a category filter is applied, what format results take, or any access constraints.

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?

A single front-loaded sentence with the resource named first and the result volume and content shape stated immediately. No filler, no restatement of the tool name beyond what is 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?

For a simple, read-only lookup with one optional parameter and no output schema, the description supplies the essentials: what is returned, how many items, and that remediation guidance is attached. Missing only the filtering interaction detail and any hint of the return structure, which is a modest gap given the tool's low complexity.

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 single parameter is an optional enum documented as 'Optional category filter. Defaults to all.', so the schema already does the param work. The description adds nothing about filtering behavior, and leaves a real ambiguity: whether 'top 25' applies overall or per selected category.

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?

Specific verb ('Retrieve') and specific resource ('top 25 common reasons municipal building control examiners reject building plans in South Africa'), plus the added payload of verified remediation steps. It is functionally distinct from siblings like get_sans_rules or pre_check_building_plan, but it never explicitly states that distinction, so an agent must infer it from the domain wording alone.

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 contains no when-to-use guidance, no preconditions, and no named alternatives. There is no signal about whether this should be called before a submission, after a rejection, or as a substitute for pre_check_building_plan, leaving the agent to guess at the workflow position.

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