PlanComply SANS 10400 Building Compliance

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

No annotations are provided, so the description carries the full disclosure burden. It does add real value by naming the statutory ratios the calculation compares against, but it never says what the tool returns (pass/fail, shortfall, computed minimums) or how missing glazed/openable areas are treated.

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 dense sentence with the standard, the metric, the threshold and the room scope all front-loaded. Every clause carries information an agent would otherwise have to guess.

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 annotations and no output schema, the description should also describe the result shape and the optional-parameter behavior. It covers the regulatory intent well but leaves the agent guessing what comes back and how partial inputs are handled.

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 100%, so the baseline is 3, and the description earns an increment by tying the parameters to the requirements: floor area drives the lighting minimum and openable sash area drives the ventilation minimum, with glazed area as the comparison value. It still does not clarify that the two 'actual_*' parameters are optional.

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 (calculate) plus the exact resource: SANS 10400-O natural lighting and ventilation compliance for habitable rooms, including the statutory thresholds (10% floor area, 5% openable sash). This clearly distinguishes it from the sibling calculate_stair_compliance, which covers a different part of the standard.

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 domain context implies when it applies (checking habitable rooms against SANS 10400-O), but there is no explicit when-to-use/when-not guidance and no mention of alternatives such as check_municipal_requirements or pre_check_building_plan. Nothing tells the agent what to do if only floor_area_m2 is supplied.

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

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

With no annotations, the description carries the full load, and it does disclose the actual decision rules applied (200 mm riser cap, 250 mm going, 2R+G 570–650 mm, 2,100 mm headroom), which is genuine behavioral content. However, it omits critical behavior: whether a non-compliant input returns a report of violations or an error, and how the three optional parameters (baluster gap, balustrade height) affect the verdict.

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 and the governing thresholds packed into a parenthetical that earns every token. Zero filler or restatement of the tool name.

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 five-parameter, mutation-free evaluation tool with no output schema, the description supplies the standards context an agent needs to trust the tool's scope. The remaining gap is result semantics (pass/fail reporting), which is a minor but real omission given there is no output schema to lean on.

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%, so the parameter definitions already explain each field and its limit; the description only restates a subset of those thresholds. It adds no syntax, units clarification, or defaulting behavior beyond the schema, so the baseline of 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 verb ('Evaluate') plus a clear resource ('stairway geometry and life safety') and names the governing standard (SANS 10400-M). It is distinguishable from siblings like calculate_sans_fenestration or check_municipal_requirements by domain, though the description never explicitly contrasts itself with them.

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 no guidance on when to invoke this versus pre_check_building_plan or get_sans_rules, and no prerequisites (e.g., only residential stairs, only once geometry is known). Usage is only inferable from the tool name and the standards cited.

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

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

No annotations are provided, so the description carries the full behavioral burden. "Retrieve" implies a read, and the content categories are named, but nothing is said about what happens for an unknown or unsupported municipality, whether the statutory/geotechnical rules are versioned or jurisdiction-specific, or how current the data is.

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 no filler; the retrieval verb and the content list come first. It is slightly dense in bundling four distinct content categories plus a jurisdiction scope, but no sentence 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?

This is a simple one-parameter read tool with a fully documented schema and no output schema, and the description enumerates the content categories an agent will receive. It is close to complete; only unsupported-municipality and data-currency behavior are missing.

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?

There is a single parameter with 100% schema description coverage, including worked examples of full names and abbreviations, so the schema already does the explanatory work. The description adds no additional meaning about matching behavior (e.g. fuzzy matching or handling of unrecognised names), which is the baseline 3 case.

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 states a specific verb ("Retrieve") and enumerates the concrete resources returned: submission checklists, statutory Form 1/2, geotechnical/dolomite rules, and rejection delay factors, scoped to South African metropolitan municipalities. It is clear what the tool returns, but it does not differentiate itself from the sibling get_common_rejection_pitfalls, whose scope appears to overlap with the "rejection delay factors" content listed here.

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?

There is no explicit when-to-use, when-not-to-use, or prerequisite guidance. The only implied usage is that an agent should call it when it needs municipal submission requirements, and the overlap with get_common_rejection_pitfalls is left unresolved rather than routed.

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

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.

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

No annotations are provided, so the description carries the full disclosure burden. It mentions 'checkout details' but never says whether this is a static price list, whether prices vary by jurisdiction or plan, whether checkout requires an authenticated account or initiates a transaction, or whether any side effects occur. For a commerce-facing tool with zero annotation coverage this is a significant gap.

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 verb and all three resource categories, and no filler. Nothing could be removed without losing scope information.

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 and no annotations, the description is the only source of information about results, yet it does not say what the response looks like (price tiers, package sizes, a checkout link?). For a zero-parameter lookup tool the purpose is adequate, but an agent cannot predict the return payload.

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 tool takes zero parameters, which is the baseline-4 case; there is nothing for the description to disambiguate. The description does implicitly confirm the call is argument-free by framing it as a plain retrieval.

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 gives a specific verb ('Retrieve') and a concrete resource set: plan audit credit packages, volume discounts, and checkout details. An agent can immediately distinguish this pricing/commerce tool from the compliance-calculation siblings. It stops short of naming a sibling or explicitly stating it is the only pricing tool, so it is not a 5.

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: an agent infers it should call this when it needs credit costs or purchase information. There is no explicit statement of when to call this versus the compliance tools, nor any prerequisite or exclusion. The narrow pricing scope makes the inference easy, but the guidance is not spelled out.

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

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

No annotations are provided, so the description carries the full behavioral burden. It implies a read-only search, but does not state whether results are paginated, how many clauses are returned, whether search is case-sensitive, or what the response format looks like. For a search tool with zero annotation coverage, this is a significant gap.

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 a single, front-loaded sentence that identifies the tool's purpose and filters without wasted words. It is appropriately sized for a simple search tool, though it could be slightly more informative without becoming bloated.

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 read-only search tool with full schema coverage and no output schema, the description is adequate but incomplete. It explains what can be searched but not how results behave, whether filters combine, or when to prefer this tool over sibling compliance and calculation tools. Additional behavioral context would raise the score.

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%, so all three parameters are already documented in the schema. The description adds the Part range 'A to XA' and a category list, which is mildly useful but largely mirrors the schema examples. Baseline 3 is appropriate when the schema does the heavy lifting.

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 gives a specific verb and resource: 'Search and query South African National Building Regulations (SANS 10400) clauses.' It also names the two major filtering dimensions (Part and category), making the tool's purpose clear. It does not explicitly differentiate itself from sibling tools such as pre_check_building_plan or calculate_stair_compliance, so it falls short of a 5.

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 indicates what the tool searches but gives no explicit guidance on when to choose it over siblings like pre_check_building_plan or get_common_rejection_pitfalls. There are no exclusions, prerequisites, or workflow hints. Usage is only implied by the search-oriented wording.

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

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

With no annotations, the description must carry the behavioral burden. It usefully discloses that the tool returns a compliance readiness score, defect warnings, and a submission checklist, but it does not state whether the operation is read-only, whether data is stored, or any auth/rate-limit 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?

The description is a single front-loaded sentence with no wasted words. It covers the action and the main outputs efficiently.

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?

The schema fully documents the 11 parameters, and the description names the return components. However, for a complex pre-submission validation tool with no annotations or output schema, it lacks operational context such as how it relates to sibling validation tools and what the output format or limits are.

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%, so all 11 parameters are already documented in the input schema. The description adds no additional parameter meaning beyond what the schema provides, which matches the baseline of 3 when the schema does the heavy lifting.

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 states a specific action and resource: automated multi-point regulatory validation on building plan specifications. It also names the return artifacts, making the tool's role clear, though it does not explicitly distinguish itself from siblings such as check_municipal_requirements or get_common_rejection_pitfalls.

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 'pre_check' name and 'compliance readiness score' imply use before submission, but the description gives no explicit when-to-use guidance, exclusions, or sibling alternatives. The intended usage is inferable but not spelled out.

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