engineering

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

With no annotations, the description carries the full burden of behavioral disclosure. It usefully states that the tool returns a compliance score, renovation cost estimate, deadline pressure, and priority measures. However, it does not explain underlying methodology, assumptions, or any side effects, leaving some behavior implicit for a pure assessment tool.

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 filler. It names the action, the target, and the key outputs efficiently, which makes it easy for an agent to parse quickly.

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 and no annotations, yet the description only names the outputs without defining scales, units, deadline-pressure semantics, or why all seven parameters are required. For a tool with multiple required inputs and non-trivial outputs, the description leaves notable gaps that an agent would need to infer.

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 only 43%, and the description does not compensate for the undocumented parameters (year_built, current_epc, has_solar_pv, floor_area_m2). The description lists outputs that imply dependencies on these inputs, but it adds no actual parameter‑level meaning beyond the three fields already described in 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?

The description clearly states a specific verb ('Assess') and a specific resource ('EU EPBD (2024) compliance'), and lists the main outputs. It is easy to distinguish from sibling tools, which focus on other frameworks (e.g., MEES, NIS2, UAE BIM), even though it doesn't explicitly name any alternative.

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 guidance about when to use this tool versus other compliance or assessment siblings. The description implies the obvious use case (EU EPBD compliance) but provides no context on exclusions, prerequisites, or when a different tool might be more appropriate.

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 provided, the description carries the full disclosure burden. It does reveal the output set and the main methodological concepts (per-scope tCO2e, CRREM compliance, net-zero gap, priority actions). However, it does not disclose assumptions around missing utility inputs, defaulting behavior, or calculation boundaries.

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 two tight sentences with no filler. The first sentence establishes the tool's purpose and scope, and the second enumerates the return values. Every phrase adds information and is front-loaded effectively.

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 tool with 10 undocumented parameters, no annotations, no output schema, and an overlapping sibling, this description is incomplete. It covers the output side reasonably well but leaves input semantics, parameter relationships, defaults, and selection criteria entirely unaddressed.

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 0% with 10 parameters, and the description does not explain any of them. It never mentions building_type, floor_area_m2, location, year_built, elec_kwh_year, gas_kwh_year, renewable_pct, or how these map to scopes. The description fails entirely to compensate for the undocumented 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?

The description clearly identifies the tool's domain: building carbon footprint with Scope 1/2/3, CRREM stranding, and embodied carbon, and it names the specific returns. It does not explicitly distinguish this from the overlapping sibling calculate_carbon, so it misses the differentiation needed for 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?

There is no guidance on when to use this tool versus alternatives such as calculate_carbon or assess_epbd_score. The description says what the tool computes, but not when it should be selected, what prerequisites exist, or when another sibling would be more appropriate.

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 provided, the description carries the full burden of behavioral disclosure. It describes the output (score, complexity, domain scores, RAG, recommendations) but does not explicitly state whether the tool is read-only, what side effects exist, or execution details. It implies a non-destructive assessment but does not confirm it. The output description is helpful but lacks explicit transparency about side effects or limitations.

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, concise sentence that front-loads the core purpose and then lists the output components. It avoids unnecessary words and is easy to parse. It could be slightly more structured (e.g., bullet points) but is well within acceptable length and clarity.

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?

Given the tool's complexity (8 required enum parameters, no output schema, no annotations), the description is somewhat thin. It lists the returned items but does not explain what 'RAG' stands for, how to interpret the score, or how parameters influence outcomes. While the output list is helpful, the absence of parameter guidance and methodological context leaves room for ambiguity. Adequate but not complete.

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 0%, and the description does not mention any of the 8 parameters. The enum values are somewhat self-explanatory (e.g., 'office', 'pre1945'), but the description provides no guidance on how to select them or how they affect the result. Since the schema carries no descriptions, the description must compensate, but it does not, leaving the agent to rely solely on enum names. This is a significant gap.

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 purpose: 'Building Readiness assessment for change-of-use / conversion.' It specifies the verb (assessment), the resource (building readiness), and the context (change-of-use/conversion). It also lists the output components (score, complexity, four domain scores with RAG, recommendations), making it distinct from other assessment tools in the sibling list.

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 implies the usage context—'for change-of-use / conversion'—but does not explicitly state when to use this tool versus alternatives or provide any exclusions. It does not name sibling tools or give conditions for selection, so an agent must infer when this is the right choice. Adequate but not proactive.

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 provided, the description carries the full behavioral burden. It does disclose the outputs (carbon intensity, benchmark, prioritised reduction measures with payback), but it omits assumptions, default behavior for missing optional parameters, and any limitations or data requirements.

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 sentence that front-loads the core purpose, then lists the return outputs without waste. The standard references add useful precision without bloat.

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 description states what the tool returns, which is useful given there is no output schema, but it omits required parameter semantics, default behaviors, and sibling differentiation. For a five-parameter calculator with no annotations, this is minimally adequate but leaves meaningful gaps.

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 only 60%, leaving floor_area_m2 and construction_year undocumented. The description does not compensate by explaining parameter meaning, units, or defaults such as using benchmark values when energy_kwh_year is absent. It adds little semantic value beyond 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?

The description names a specific verb and resource: calculating operational and embodied carbon plus the net-zero gap, and cites CIBSE TM65 / RICS WLCA. This is clear and specific, though it does not explicitly differentiate itself from siblings like building_carbon_footprint or eu_cost_benchmarking.

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 use this tool over related carbon or benchmarking tools. It neither states typical use cases nor names alternatives, so an agent must infer selection context from the sibling list alone.

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 burden. It does disclose that this is a calculation that returns PUE score, efficiency rating, annual cost estimate, and engineering recommendations. However, it omits behavioral details such as assumptions behind the annual cost estimate or the efficiency rating scale, which could matter for interpreting results.

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, efficient sentence that front-loads the operation and scope, then lists all expected outputs. Every phrase earns its place with no redundancy or filler.

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?

Given the simple calculator nature and fully documented parameters, the description is largely complete: it states what it calculates, for whom, and what it returns. It could be improved by explaining the efficiency rating scale and cost assumptions, but these are minor gaps for a low-complexity tool.

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 each parameter already includes a description and an example. The tool description adds no parameter-level semantics, but none are needed because the schema fully documents all four required inputs.

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 opens with a specific verb ('Calculate'), names the exact metric and scope ('Power Usage Effectiveness (PUE) for a data centre or server room'), and lists four concrete return components. This clearly distinguishes it from sibling tools like estimate_cooling_load or thermal_load.

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 a clear use context—data centres and server rooms—which tells an agent when this tool is relevant. It does not explicitly name alternatives or exclusions, but the domain context and unique PUE scope are sufficiently clear given the sibling list.

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 must carry the full burden. It communicates that this is a read-only assessment by listing return values such as feasibility score and timeline. However, it does not disclose limitations, assumptions, whether utility approval is included, or what the feasibility score represents.

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, focused sentence that packs in scope, utilities, and expected outputs without any filler. It is front-loaded with the core action and resource, making it easy to parse and act on.

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 description is adequate for a simple feasibility assessment tool: it states what it does and what it returns. However, with 6 required parameters, no output schema, and no annotations, it lacks guidance on parameter units, score interpretation, or any caveats, leaving some gaps for an agent trying to invoke it correctly.

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 0% for 6 required parameters, and the description does not explain the meaning of site_location, power_requirement_mw, voltage_level, intended_use, has_existing_supply, or target_completion_year. It only references the UAE utilities, leaving the agent to infer parameter semantics from parameter names and enums.

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 uses a specific verb, 'Assess', with a clear resource, 'UAE grid connection feasibility', and names the relevant utilities (DEWA/ADDC/SEWA/FEWA). This clearly distinguishes it from sibling tools like assess_epbd_score or uae_climate_ghg, which address different UAE-related assessments.

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 conveys an implied use case: evaluating grid connection feasibility for UAE locations. However, it does not explicitly state when to use this tool over alternatives, nor does it mention any prerequisites or conditions where another tool would be more appropriate.

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?

There are no annotations, so the description must carry the behavioral transparency burden. It does disclose the kind of output (score, maturity, fine exposure, remediation actions) and the score range, but it does not state whether the assessment is read-only, whether results are computed locally, or whether there are any side effects or prerequisites. This is a moderate gap for an assessment tool.

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 one focused sentence with no filler. It front-loads the purpose and immediately provides the most important output details, making it easy to scan and understand.

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?

Given 11 required parameters, 9% schema coverage, no annotations, and no output schema, the description is too thin. It explains what the tool returns but gives no guidance on parameter semantics, particularly for sector and organisation_size, and no indication of when to choose this tool over the many related readiness/checking siblings. An agent would need additional knowledge to call it correctly and confidently.

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 only 9%, with 10 of 11 parameters being undocumented booleans. The description does not compensate for this at all; it only describes outputs, not inputs. Although parameter names like has_ciso are self-explanatory, key parameters such as organisation_size enum values ('essential', 'important', 'other') and sector are not explained, forcing the agent to guess their meaning in NIS2 context.

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?

Description states a specific verb ('Assess') and a specific resource ('NIS2 Directive (EU 2022/2555) compliance readiness'), which clearly distinguishes it from sibling tools like check_uae_cybersecurity or mees_checker. It also mentions concrete outputs (score range, maturity level, fine exposure, remediation actions), making the tool's purpose unambiguous.

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 NIS2 Directive reference implies the tool should be used for EU NIS2 compliance assessments, but there is no explicit statement about when to use it versus alternatives, nor any exclusion criteria. The usage context is inferable but not directly stated.

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 burden and does disclose the core behavior: it returns mandate status, compliance score, required LOD, and submission checklist. It does not, however, clarify edge cases (e.g., emirate='other'), whether any data is persisted, or how mandatory thresholds are applied.

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 sentence front-loads the purpose and jurisdiction, then lists the returned outputs. There is no filler or repetition of schema details.

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 tool with eight required parameters, no annotations, and no output schema, the description is minimal. It provides a good high-level summary but omits practical context such as parameter meanings, emirate fallback behavior, or how the compliance score relates to the returned checklist.

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 only 13%, so the description needed to compensate, but it explains nothing about the eight required parameters. Names like building_area_m2 and emirate are self-evident, but terms such as has_bep remain ambiguous (BIM Execution Plan vs. building energy performance) without any clarification in the description.

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 names a specific verb ('Check'), a concrete resource ('UAE BIM mandate applicability'), and cites exact regulations (Dubai Circular 196, Abu Dhabi DMT, Sharjah), which also separates it from generic BIM or UAE sustainability siblings. It also previews the result type, making the tool's intent unmistakable.

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 intended use is implied by the title and description: use this for UAE BIM mandate checks. However, it does not state when to prefer it over related tools such as dgnb_bim_readiness or building_readiness, nor does it give exclusions or explicit conditions.

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 present, the description carries the disclosure burden. It explicitly states the assessment nature and the exact outputs: applicable framework, compliance score, critical gaps, and mandatory controls. This implies a non-mutating calculation, though it does not discuss edge cases or data handling.

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 packs in the domain, the relevant frameworks, and the output contract. There is no filler or tautological 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 an 8-parameter tool with no output schema and no annotations, the description covers return values but omits how the inputs influence framework selection and what exclusions apply relative to other compliance checks. It is concise but leaves the agent to infer part of the decision logic.

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 only 13%, and the description does not compensate for this gap. It does not explain how organisation_type, emirate, or the boolean control flags map to the listed frameworks. The parameter names are somewhat self-evident, but the description adds little meaning beyond the raw 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?

The description uses a specific verb ('Assess') and a specific resource ('UAE cybersecurity regulatory compliance'), and it names distinct frameworks (NESA IAS, Dubai ISR, CBUAE, TDRA). This clearly distinguishes it from sibling tools like check_nis2_readiness and check_uae_bim_compliance, and the return contents are also stated.

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 provides clear context: use this tool when dealing with UAE cybersecurity regulatory compliance under NESA IAS, Dubai ISR, CBUAE, or TDRA. It does not explicitly list exclusions or alternatives, but the context is specific enough for an agent to route to this tool correctly.

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?

Because no annotations are present, the description carries the full burden and does disclose that the tool computes a score, flags critical failures, and returns recommended checks. It does not explain how 'unknown' answers are handled, how the score is calculated, or whether the operation persists any data.

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?

Two sentences with no filler: the main deliverable comes first, the checklist scope second, and the key caveat last. Every sentence contributes meaningful 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?

The description gives a useful high-level view of what the tool returns, which matters because there is no output schema. It does not specify the score scale, how blocking failures are determined, or how the purpose parameter changes behavior, leaving some uncertainty for a 12-question scoring tool.

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 schema already documents all parameters and answer IDs, but the description adds useful meaning by explaining that the checklist spans financial, technical, cyber (NIS2), and energy (EPBD) categories. It also hints that purpose selects the NIS2 vs EPBD lens, which adds context beyond the schema's bare 'Vetting purpose' text.

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 deliverable—a NIS2/EPBD contractor vetting score—and its source (12-question checklist) and primary outputs (blocking failure flags and recommended checks). It does not explicitly distinguish itself from sibling tools like assess_epbd_score or check_nis2_readiness, so it stops 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 phrase 'contractor vetting' plus the NIS2/EPBD scope clearly implies when this tool is relevant, and the caveat 'Not a formal due-diligence report' sets a boundary. However, there is no explicit when-not-to-use guidance or comparison against alternative sibling tools.

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 provided, the description carries the full burden of explaining behavioral traits. It discloses that this is a self-assessment, returns several specific outputs, and explicitly warns that it is not a formal DGNB audit. This meaningfully clarifies the tool's limits and what an agent should not expect, though it does not detail data handling or side effects, which are relatively minor for an assessment tool.

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 two sentences with no wasted words. It front-loads the core function, lists the key outputs, and ends with an important caveat. Every sentence earns its place.

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 description covers the core purpose, the main outputs, and an important boundary condition. Combined with the fully documented schema, an agent has enough to understand how to call the tool and what to expect in return. It is not fully complete because it omits explicit guidance on when to prefer this tool over closely related BIM or readiness assessments, but this is a moderate gap given the output list and schema coverage.

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 baseline is 3. The description adds some useful framing by mentioning the 20-question checklist, which relates to the answers object, but it does not add substantive meaning to the individual answer values or cert_target beyond what the schema already provides.

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 a specific action: it provides a DGNB certification pre-score and BIM maturity self-assessment based on a 20-question checklist. It distinguishes itself from siblings like check_uae_bim_compliance by referencing DGNB and ISO 19650, and it explicitly sets expectations with 'Not a formal DGNB audit.'

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 useful context about the tool being a self-assessment and pre-score rather than a formal audit, which implies early-stage or indicative use. However, it does not explicitly state when to use this tool versus related alternatives such as building_readiness or check_uae_bim_compliance, nor does it provide applied guidance on selecting between them.

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 disclosure burden. It adds meaningful context by calling the result 'Indicative' and by specifying the output dimensions. However, it does not disclose assumptions, data sources, accuracy limits, or the exact return format.

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 compact: one substantive sentence followed by the single caveat 'Indicative.' It front-loads the core behavior and output without repeating schema field descriptions or adding filler.

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 non-destructive estimation tool, this is sufficient: it states the analytic inputs, the high-level output structure, and the indicative nature, while the schema documents all parameters. It would benefit from explicit units or a return-value shape, but nothing essential for selecting or invoking the tool is 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?

Schema coverage is 100%, so the baseline is 3. The description adds value by explicitly naming current EPC, floor area, and heating type as the drivers of the roadmap, implying that other fields are contextual labels rather than calculation inputs.

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 identifies the deliverable—a 3-phase renovation roadmap with cost ranges, energy savings, and EPC trajectory—and the EPBD framing helps distinguish it from the sibling tools. It lacks an explicit action verb like 'generates' or 'calculates', but the purpose is unambiguous.

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 or when-not-to-use guidance, and no alternatives are named. The EPBD-style, staged-renovation framing and the word 'Indicative' imply the intended scenario of rough renovation planning, but the agent must infer this from context.

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 provided, the description carries the full burden, and it delivers well: it discloses scope-screening behavior, the four KPIs computed, and adds the crucial caveat that 'the regulation mandates reporting, not target values' — preventing the agent from misreading outputs as compliance verdicts. It does not disclose handling of missing optional inputs or return format, but the core behavioral profile is honestly and usefully stated.

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?

Three sentences, zero filler: legal identity, core functionality, and a high-value caveat. Each sentence earns its place, and the functional verbs appear immediately after the legal framing.

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?

No output schema exists, so the KPI list and scope-determination statement give the agent a solid expectation of what the tool returns. Missing details — return format and behavior when optional inputs are absent — are minor for a stateless calculation tool whose inputs are fully self-documented.

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 schema already maps parameters to KPIs ('WIN: total water input (m3/yr), for WUE', 'EREUSE waste heat reused, for ERF'). The description adds the 500 kW threshold context for it_power_kw and the KPI acronym list, but this is marginal value over the schema — the 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 names a specific resource ('data-centre reporting pack') with explicit verbs: 'determines reporting scope' and 'computes the mandated KPIs PUE, WUE, ERF and REF'. The EED legal citations plus the enumerated KPI set clearly differentiate it from siblings like calculate_pue, which handles only a single KPI.

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?

Clear context is established via the legal basis (Dir (EU) 2023/1791 Art.12 + Del. Reg (EU) 2024/1364) and the applicability threshold ('IT power >= 500 kW'), which tells an agent when this tool is the right choice. It does not explicitly name alternatives or state when-not-to-use, but the regulatory framing makes the intended scenario unambiguous.

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 provided, the description carries the full burden of behavioral disclosure. It does disclose the output types (required capacity, installed capacity with redundancy, system recommendation, annual energy), but says nothing about assumptions, limitations, or how inputs affect behavior. An agent gets no warning about data-centre specifics, methodology sensitivity, or accuracy expectations.

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?

Two efficient sentences front-load the core purpose and then list outputs with no wasted words. It could be slightly better structured with usage guidance, but for what it includes, the prose is tight and scannable.

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 6-required-parameter tool with no output schema and no annotations, the description is too thin. It tells the agent what the tool returns but not how to populate the inputs correctly, when to choose it, or what methodological constraints apply. The high-level output list is useful but not 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?

Schema description coverage is only 17%, and the description does not compensate by explaining parameters like climate_zone, space_type, occupancy_persons, or floor_area_m2. It indirectly ties redundancy to 'installed capacity with redundancy' and implies the methodology, but most parameters remain semantically underdocumented.

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 names a specific action ('Estimate cooling load') with explicit methodology references (CIBSE Guide B2 / ASHRAE) and lists concrete outputs. It does not explicitly compare itself to sibling tools like thermal_load or heatpump_heatloss, but the methodology and output detail provide enough differentiation to be clear.

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 choose this tool over alternatives such as thermal_load or heatpump_heatloss. It implies the use case (cooling load estimation) but provides no exclusions, prerequisites, or decision rules.

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 provided, the description carries the full behavioral disclosure burden. It discloses that the tool is indicative, that it returns per-m2 and total cost ranges plus a breakdown, and that results should be validated externally. This is strong transparency for an estimation tool, though it could note assumptions or data currency.

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?

Two tightly written sentences with no filler. The main purpose is front-loaded, followed by output details and a caveat. Every sentence contributes useful 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?

The description provides a strong overview of purpose, inputs, outputs, and limitations despite having no output schema or annotations. The main gaps are the lack of an explicit mention of the required floor_area_m2 parameter and the absence of currency specification, which is notable for an international cost tool.

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 low at 43%, and the description names many parameters (country, project type, specification, procurement, programme, BIM) but adds limited semantic depth beyond their names. It does clarify that floor area relates to both per-m2 and total cost outputs. This partially compensates for the sparse schema descriptions but not fully.

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 uses a specific, informative verb phrase ('Parametric construction cost benchmark') and names the geographic scope and the main dimensions it covers. It clearly distinguishes this tool from the energy, carbon, and regulatory siblings by focusing on construction cost outputs.

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 clear context for when to use the tool: it is an indicative parametric estimate that should be validated against current cost indices. It does not explicitly name alternatives or exclusions, but the sibling tools are in different domains, so the usage context is clear enough.

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 provided, the description carries the behavioral burden. It states the computational scope and adds the important limitation 'Indicative, not a stamped design,' which warns against over-trusting the output. It does not detail the return format, but for a calculation tool the description covers the key behavioral expectations.

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 three compact sentences with zero redundant words. The purpose is front-loaded, the computational outputs are listed in the second sentence, and the limitation comes last. Every sentence earns its place.

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 description explains the type of calculation (ULS, SLS, fire protection) and the indicative nature, which is sufficient for an agent to understand the scope. There is no output schema, so the description partially compensates by enumerating the computed results, though it does not specify the exact response structure. Given the moderate complexity of the tool, this is nearly complete.

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 input schema already documents all nine parameters with names, types, and units. The description adds no parameter-level detail beyond the general summary of what is computed. It does not clarify dependencies such as exposure being concrete-only or which parameters apply to steel vs. composite, but the baseline of 3 is appropriate given complete schema coverage.

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 opens with 'Preliminary Eurocode beam design' and explicitly lists the materials (steel EC3 / composite / reinforced concrete EC2), immediately distinguishing this from the sibling eurocode_column_checker. It also names specific outputs (selects a section, computes ULS bending & shear utilisation, SLS deflection, fire protection), making the tool's function unambiguous.

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 word 'Preliminary' and the explicit 'not a stamped design' clearly convey when the tool is appropriate and when it is not. It lacks an explicit pointer to an alternative or a direct 'use this when...' statement, but the scope is clear enough for an agent to route correctly for beam calculations.

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?

Since no annotations are provided, the description carries the full burden of behavioral disclosure. It names the computed outputs and adds the important limitation 'Indicative, not a stamped design,' signaling that results are advisory rather than certifying. It does not detail assumptions or defaults, but the key behavioral caveat is present.

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 compact and well structured: two sentences, no filler, with the tool's purpose, scope, outputs, and limitation all clearly stated. The most decision-relevant information is front-loaded.

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 description usefully names all key outputs despite the absence of an output schema. However, for a 9-parameter tool with material-specific branches and no annotations, it omits branch-specific prerequisites and conditional parameter relationships, leaving an agent potentially able to call the tool with only the three required fields and receive an error or invalid result.

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 baseline is 3 and the schema already documents every parameter. The description adds the steel/RC branch context but does not explain branch-specific dependencies, such as requiring a steel section and buckling curve for steel or depth/width/reinforcement for concrete.

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 opens with 'Eurocode axial column buckling check' and explicitly names both relevant codes (steel EC3 6.3.1 and RC EC2 5.8), making the resource and action unambiguous. It also lists concrete return values, and the axial column focus clearly distinguishes it from sibling tools such as eurocode_beam_designer.

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 clear context for what the tool covers—axial column buckling for steel or RC under Eurocode—but it does not state when to prefer this tool over alternatives or when not to use it. The sibling eurocode_beam_designer exists, but no explicit routing or exclusion guidance is provided.

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 burden, and it does add value by disclosing that the tool returns indicative ranges and a contact CTA. However, it does not clarify whether calling the tool has side effects such as triggering contact, storing the request, or creating any commitment, leaving meaningful ambiguity.

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 states the action and enumerates the key return values with no filler. It is appropriately sized for a straightforward calculator-style tool.

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 description covers the return envelope well given there is no output schema, and the required parameters are visible in the input schema. Still, with no annotations and low schema coverage, it leaves gaps around how inputs should be interpreted, what 'contact CTA' means behaviorally, and any limitations or exclusions for the estimate.

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 only 17%, and the description adds no parameter-level meaning beyond what the schema already names. Terms like gross_area_m2 and timeline_weeks are self-evident in isolation, but the description does not explain how disciplines, geography, or transaction_type affect the estimate, nor does it clarify units or constraints beyond 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?

The description uses a specific verb ('Generate an indicative') and a specific resource ('Technical Due Diligence (TDD) fee estimate'), and immediately names the main outputs: preliminary/full fee ranges, turnaround days, and contact CTA. It is clearly differentiated from the sibling calculators and checkers, none of which focus on TDD fee estimation.

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?

No guidance is provided on when to use this tool versus alternatives, nor on when not to use it. The description does not reference any sibling tool or state whether this is appropriate for early-stage budgeting versus a formal engagement.

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 present, so the description carries the burden. It discloses that results are estimates based on typical U-values/SCOP rather than measured data, and it enumerates what the tool returns. This prevents over-trusting the outputs, though deeper assumptions behind age band and location are not detailed.

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?

Two dense sentences with no redundancy. The purpose, standard, key inputs, outputs, and caveat are all front-loaded and each clause contributes useful 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?

For a 10-parameter tool with no output schema, the description covers core return values, input categories, and the estimate caveat. It omits explicit mention of override parameters such as flow temperature and design temperatures, but those are schema-described and secondary to the core calculation.

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 60%, so the schema already documents several parameters. The description adds meaning by identifying the governing physical inputs: floor area, storeys, age band, location, and glazing. It also links them to the calculation purpose without merely restating parameter names.

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 and resource: 'Domestic whole-dwelling fabric + ventilation heat-loss estimate' for 'heat pump sizing', tied to BS EN 12831 / MCS. It also lists concrete outputs, making it clearly distinguishable from cooling-load or general thermal tools.

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 usage context is clear: domestic, whole-dwelling, heat pump sizing, using standard assumptions. It does not explicitly name sibling alternatives or say when not to use it, but the purpose and domain are specific enough to route an agent correctly.

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 provided, the description carries the full transparency burden. It discloses what is tested, what is advisory, and what outputs the user receives (compliance, can-let, cost cap, penalties). This gives an agent a clear expectation of behavior beyond the simple tool name.

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 three tightly packed sentences with no filler. Jurisdiction and subject are front-loaded, the in-force vs proposed distinction is explicit, and return categories are listed at the end. Every sentence contributes 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?

For a two-parameter checker with no output schema, the description covers the regulation, jurisdiction, property scope, test threshold, advisory uplift, and output categories. It does not detail the exact result format, but that is not essential for selecting and invoking the tool correctly.

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 0%, so the description must compensate. It does: property_type is tied to 'domestic and non-domestic', and current_epc_band is framed by the EPC E minimum and EPC C/2030 uplift, adding regulatory meaning that bare enum values lack.

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 opens with a specific verb and resource: 'MEES check for private rented property' in England & Wales. It then pinpoints the exact regulatory test (in-force EPC E minimum) and the advisory EPC C/2030 uplift, clearly differentiating this from the many other EU/UAE/UK tools in the sibling list.

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 intended use is clear from the scope ('England & Wales', 'private rented property', 'MEES check'), and the description explicitly warns that the EPC C element is 'not yet law' and 'advisory only', which prevents misuse. It does not name alternatives or say when not to use it, but no sibling tool appears to cover the same MEES check.

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 disclosure burden. It clearly states a pass/fail return and a follow-up to CIBSE TM59, plus the caveat 'Indicative,' which is useful behavioral context. It does not detail edge-case behavior, but it covers the core behavior sufficiently.

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 two sentences, with the core purpose and scope front-loaded. Every clause adds relevant information: the regulation, the test criteria, the return type, and the indicative caveat. No redundant filler is present.

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 6-parameter check tool with no output schema and no annotations, the description is reasonably complete. It explains what the tool checks, what it returns, and what happens on failure. It does not explicitly list all parameters or prerequisites, but the schema covers required fields and enums, and the added caveat 'Indicative' sets user expectations.

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 only 33%, so the description must compensate. It explains that glazing area is based on orientation, risk zone, and cross vs. single aspect, which adds meaning to most_glazed_facade, location_risk, and cross_ventilation. It also mentions minimum free ventilation area, covering provided_free_area_m2. However, floor_area_m2 and glazing_area_m2 are not directly elaborated, leaving some reliance on naming conventions.

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 performs a UK Approved Document O 2021 simplified-method overheating check for new residential buildings, with specific tests for glazing area and ventilation. It distinguishes itself from sibling tools by referencing the exact regulatory framework and method.

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 explicit guidance on when to use this tool instead of siblings. It mentions that it points to CIBSE TM59 modelling on failure, which implicitly indicates a fallback, but it does not state when an agent should select this tool over related tools like thermal_load or estimate_cooling_load.

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 behavioral disclosure burden. It discloses that the tool returns charge points, cable routes, minimum power, and cost caps/exemptions, and it flags 'Indicative' as a limitation. It does not explain the underlying methodology, but the output behavior is clearly stated.

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 three compact sentences with no redundant wording. It front-loads the purpose and scope, then lists outputs and the 'Indicative' caveat. Every sentence earns its place.

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 5-parameter calculator with no output schema, the description names the key outputs and applicability scope. It does not explicitly state input dependencies like 'dwellings for residential' or 'covered_car_park for non-residential', but these are partly inferable from the schema descriptions. Overall, this is reasonably complete for correct invocation.

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 60%, so the description needs to add some parameter-level meaning. It adds useful domain context like the 1-in-5 cable route rule for non-residential, but it does not clarify parameter dependencies such as when dwellings or covered_car_park should be provided. The schema covers some fields, but the gap for the remaining parameters is not fully compensated.

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 names the exact regulation (UK Approved Document S 2021), the resource (EV charge-point requirements), and the applicable scope (new build/major renovation, residential/non-residential). This clearly differentiates it from sibling tools like part_o_overheating or uk_planning_checker.

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 states clear applicability for new build and major renovation in residential and non-residential settings. It does not explicitly list exclusions or alternatives, but the scope is specific enough for an agent to know when to select this tool.

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?

There are no annotations, so the description carries the burden of behavioral disclosure. It does disclose that the tool computes and returns several financial metrics, which implies a non-mutating calculator. However, it does not mention assumptions, interpretation of the verdict, whether inputs are persisted, or any limitations such as the efficiency gain cap.

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 concise sentence that front-loads the tool's purpose and then lists the full set of returned values. There is no filler, repetition, or unnecessary detail; every part of the sentence contributes useful 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?

The description provides a solid list of outputs but is incomplete for an unannotated tool with no output schema. It does not explain the verdict, the meaning of 'current manual cost', or default assumptions. Core callability is present, but an agent would still have to infer several operational details.

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 50%, with team_size, hourly_rate, and implementation_time_months lacking descriptions. The tool's description focuses entirely on outputs and adds no explanation of parameters, their units, or their significance. It does not compensate for schema gaps or clarify how the inputs relate to the returned metrics.

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 identifies the tool as an Engineering ROI calculator and enumerates the exact outputs it returns: manual cost, annual saving, net benefit, ROI %, payback months, 3-year NPV, and a verdict. This is a specific verb-plus-resource description that is easily distinguished from all sibling tools, none of which provide ROI calculations.

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 use this tool versus other tools. It does not state the intended scenario, prerequisites, or exclusions. While the name and sibling list imply it is the only ROI option, no explicit usage context or alternative selection guidance is provided.

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 behavioral burden. It usefully discloses that validated SAP 10 fuel factors are used and that official EPC bands require a full assessment. However, it does not clarify behavior when no parameters are supplied, what the return values look like, or how invalid fuel inputs are handled.

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?

Two focused sentences: the first states the tool's capabilities, the second adds the key limitation. No filler, no repetition of schema fields, and the caveat is positioned where it matters.

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 description is adequate for normal usage but incomplete for edge cases. All parameters are optional, yet there is no note about what happens with an empty invocation, and there is no output schema or return-format description. Naming an alternative carbon/EPC sibling would also improve completeness.

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 baseline is 3. The description adds the relationship between inputs and outputs and mentions validated fuel factors, but most parameter meanings are already present in 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?

The description states a specific purpose: a UK SAP 10.3/SBEM EPC precheck that maps SAP ratings to EPC bands and/or computes annual CO2 and primary energy. It clearly distinguishes itself from a full official SAP/RdSAP assessment.

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?

It explicitly says the official EPC band is cost-based and requires a full SAP/RdSAP assessment, which tells the agent when not to rely on this precheck. It does not name sibling tools like calculate_carbon or building_carbon_footprint, so cross-tool routing is not fully explicit.

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 burden of disclosing behavioral traits. It only says the tool 'Returns' values, which implies a read-only calculation, but it does not state whether there are side effects, assumptions, accuracy limitations, or any state changes. For an unannotated tool, this is insufficient.

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, dense sentence that front-loads the tool's purpose and lists its outputs without wasted words. It is efficient and immediately scannable by an agent.

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 7-parameter calculator with no output schema, the description is not complete enough. It lists return values but omits the meaning of most inputs, does not explain assumptions or units beyond a vague 'units', and leaves the agent to infer critical details from the schema alone, which is also sparse.

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 low at 29%, and the description does not explain the required parameters such as it_load_kw, redundancy, ambient_temp_c, or ups_efficiency_pct. The only partial addition is the CRAC/CRAH/DLC/immersion comparison, which weakly maps to the cooling_type enum, but this does not compensate for the overall lack of parameter guidance.

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 identifies the tool as a thermal load estimator for data centres / critical facilities and enumerates the specific outputs it returns (heat load, cooling capacity, PUE, etc.). However, it does not explicitly differentiate itself from the sibling tool estimate_cooling_load, so the distinction is left mostly to the output list.

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 phrase 'for data centres / critical facilities' provides clear context on when the tool applies. It does not explicitly mention when not to use it or name alternatives such as calculate_pue or estimate_cooling_load, but the domain scoping is unambiguous.

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 full responsibility for disclosing behavior. It does disclose a meaningful limitation ('Grid factors carry base-year/confidence caveats'), which adds transparency beyond the schema. However, it does not state what the tool returns (e.g., units, format, or whether a range is provided), leaving a notable gap for a calculation tool.

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?

Two dense sentences with no filler. The primary function is stated first, followed by the legal context and a concise caveat. Every clause contributes unique information, and the description is appropriately sized for the tool's complexity.

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 description covers the tool's purpose, key inputs, and a caveat, but with no output schema it omits the return format or units (e.g., kgCO2e vs tCO2e). The mutual exclusivity of gas_m3 and gas_kwh is handled by the schema, but an agent would still lack certainty about what the tool returns, which is important for correct invocation.

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 75% and already documents three parameters, but the description adds crucial meaning for 'emirate' by naming Dubai/Abu Dhabi/national emission factors. It also maps 'electricity and gas use' to the relevant parameters. This goes beyond the raw schema, though gas_m3 vs gas_kwh semantics are already well covered by schema descriptions.

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 names a specific resource (UAE Scope 1 + Scope 2 GHG), a clear operation (estimate), and the inputs (electricity and gas use). It also includes geospatial and legal specificity (emirate factors, Federal Decree-Law) that distinguishes it from generic carbon tools like calculate_carbon or building_carbon_footprint.

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 implies the tool is for UAE mandatory-reporting contexts but gives no explicit when-to-use or when-not-to-use guidance, nor does it name alternatives among the many siblings. The legal context hints at usage, but an agent must infer when this tool is preferred over calculate_carbon or building_carbon_footprint.

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 transparency burden. It discloses that results are 'Indicative, verify with the LPA' and enumerates the output shape (verdict, PD class, conditions, flags). It does not discuss side effects, but the tool is framed as a rules engine/checker, implying a read-only calculation.

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 three sentences with no redundancy: it states scope, enumerates outputs, and provides the essential caveat. Key information is front-loaded, and every sentence contributes to tool selection and safe invocation.

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?

Given 10 parameters, no annotations, and no output schema, the description does well by explaining the verdict categories, PD class, conditions, and flags, plus the legal scope and LPA caveat. It could additionally state required inputs or assumptions, but the overall picture is sufficient for an agent to invoke the tool correctly.

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 only 30%, so the description must compensate. It does add meaning by mapping flags (listed building, Article 4, conservation area, AONB) to parameters and naming some proposal types. However, it does not clarify several enum parameters such as property_type, location, or the full set of proposal values that the schema alone leaves to the agent to interpret.

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 identifies a specific resource ('UK permitted-development (GPDO 2015, England) rules engine') and a concrete set of scenarios ('extensions, loft conversions and change of use'). It also names the returned verdict categories and flags, making the tool's unique function clear relative to sibling tools.

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 provides clear context: use this for UK/England permitted-development assessments involving extensions, lofts, or change of use. It does not explicitly mention exclusions or name alternative tools, but the domain and proposal scope are specific enough to guide selection.

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