civilquants

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

Annotations declare readOnlyHint=true, implying a read-only operation, but the description clearly indicates a computation that returns output and requires paid authentication, which contradicts the read-only claim. The description adds details about tier requirements and deliverables, but the contradiction with annotations is severe.

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 verbose and includes extensive detail on standards and variants, which may be justified for a specialized tool. However, it is not concise; it contains redundancy (e.g., listing variants multiple times) and could be streamlined while preserving essential 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?

Given the complexity (5 top-level parameters, many nested, and an output schema), the description covers the tool's purpose, structural variants, tier restrictions, param examples, and deliverables. It is fairly complete, though it omits explanations for some nested parameters.

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?

With schema coverage at only 20%, the description compensates by explaining key parameters: wall_form variants with structural details, the freeboard field and its logic, and the deliverables option. It also provides example parameters and calls. However, many nested parameters under 'params' remain undocumented outside 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 it computes a BoQ for anchored retaining walls, distinguishes from the free-tier sibling compute_cantilever_wall, and specifies three structural variants. The verb 'Compute' and resource 'Anchored Wall BoQ' are specific and 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 description explicitly states that this is a paid-tier tool and mentions the free alternative compute_cantilever_wall. It provides context on when to use this tool (anchored walls) but does not systematically exclude other wall types among the many 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?

Annotations indicate readOnlyHint=true, and the description confirms it is a computation tool. It adds behavioral context like free-tier limitations, default parameter behavior, and one-shot download URLs for deliverables. It does not disclose rate limits or data retention, but given annotations, this is adequate.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded with key information (free tier, standards) and each sentence adds value. It is slightly lengthy but efficient given the tool's complexity. There is no redundancy or waste.

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 high parameter count and nested objects, the description covers core functionality, standard limitations, default behavior, and example calls. An output schema exists, so lack of return value explanation is acceptable. It could mention the output structure briefly, but overall complete for a compute 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 coverage is 0%, so the description must compensate. It provides example parameter ranges (tank_length, crate_width, crate_height) and explains the tank_type via configurations. However, many parameters like bedding_thickness, cover_to_tank_top, etc., are not explained, leaving gaps. The note about sensible defaults helps but is vague.

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 computes a stormwater attenuation tank BoQ for two configurations (crates or pipes). It distinguishes itself from sibling compute_* tools by focusing on attenuation tanks, though it does not explicitly compare to similar tools like compute_soakaway.

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 usage context: free tier only supports MMHW standard, paid tier for others, anonymous callers. It also mentions optional deliverables. However, it does not give explicit when-to-use or when-not-to-use guidance relative to siblings.

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?

The description adds value beyond the readOnlyHint annotation by disclosing the paid-tier requirement, authentication need, and deliverables option (Excel BoQ, DXF, PDF). However, it includes some internal implementation details (work categories, handler branches) that are not directly relevant to behavioral transparency.

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 excessively long and rambling, including verbose taxonomy (e.g., 'SEVENTH member of the wall family') and internal classification details that are not useful for an AI agent. While it front-loads the tier and authentication info, the rest is bloated and inefficient.

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 structural forms, standards, and deliverables, and provides example parameters. However, it does not explain the output_mode parameter or the format of the computed BoQ, relying on the output schema. Given the tool's complexity, some information 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?

With schema description coverage at 25%, the description compensates by providing example parameter values with ranges (e.g., wall_length_m=20 m (5–200)) and stating omitted parameters use sensible defaults. However, it does not explain most of the 30+ parameters, leaving gaps.

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 it computes a BoQ for a bored pile retaining wall, with verb 'compute' and resource 'BoQ'. However, it lacks clear differentiation from sibling wall tools like compute_counterfort_wall or compute_gravity_wall, despite mentioning compute_cantilever_wall as a free 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?

The description explicitly notes it's paid-tier and suggests the free alternative compute_cantilever_wall, and warns about TIER_INSUFFICIENT error. But it provides no guidance on when to use this specific wall type vs other retaining wall tools, limiting its usefulness for tool selection.

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?

The description adds behavioral details beyond the readOnlyHint annotation: paid-tier restriction, authentication error code, deliverables (xlsx, dxf, pdf), and sensible engineering defaults. No contradictions with annotations.

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 lengthy but front-loaded with the most critical info (tier restriction, purpose). Each sentence adds value, including standards, example, and deliverables. Could be slightly more concise but is well-organized.

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 (30+ parameters, nested params, deliverables), the description covers core components, measurement rules, standards, and an example call. An output schema exists, so return values need not be detailed. Nearly complete, though more could be said about edge cases or parameter interactions.

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 25%, but the description only elaborates on a few parameters (size, total_length_m, invert_depth_m, invert_gradient) in the example. Most parameters have detailed schema descriptions, reducing the burden, but the description does not guide on many important parameters like excavation_support or headwall options.

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 it computes a BoQ for a precast concrete box culvert run, listing specific catalogue sizes, components, and measurement standards. It distinguishes itself from sibling tools like compute_manhole by being the paid-tier 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?

Explicitly notes the paid-tier requirement and provides a free-tier alternative (compute_manhole). Includes example parameters and call structure, guiding when to use and how to invoke.

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?

Discloses free tier limitation, anonymous access, default behavior, deliverables download URLs, and that supplying both freeboard and retained-height is rejected. readOnlyHint annotation is consistent with compute operation; description adds value beyond annotation.

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?

Description is well-structured: starts with tier info, then wall type, parameter examples, example call, deliverables, and freeboard. Somewhat lengthy but every sentence adds relevant information; no redundancy.

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?

Covers main functionality, example usage, defaults, special behaviors (freeboard, deliverables). Given the tool's complexity (5 top-level parameters, nested params with 18 properties) and existence of an output schema, the description is sufficiently 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%, so description carries full burden. Describes example parameters (stem_height, stem_thickness_top, stem_thickness_bottom) with ranges, explains freeboard and deliverables. However, most of the 18 parameters in 'params' object are not individually explained, relying on defaults.

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 computing a Bill of Quantities for a cantilever retaining wall, specifying wall components (toe, heel, stem) and included works (excavation, blinding, drainage, backfill). It distinguishes from sibling tools like compute_gravity_wall by focusing on cantilever type.

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?

Provides clear context: free tier renders only MMHW, paid tiers for others; anonymous calls welcome; omitted parameters use defaults; explains deliverables parameter and freeboard alternative. Lacks explicit when-not-to-use but covers key usage scenarios.

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?

Annotations have readOnlyHint=true, which is consistent with a computation tool. The description adds important context: paid tier restriction, error message TIER_INSUFFICIENT, and deliverables generation. However, it includes some internal jargon (e.g., '19th use of the classed-then-legacy attribute discrimination pattern') that may not aid an AI agent. Annotations already cover the safety profile well, so description adds moderate value.

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 overly long and packed with technical detail (e.g., standard classifications, variant counts, internal pattern names). While front-loaded with the tier restriction, the verbose elaboration on standards and patterns reduces conciseness. Each sentence does not earn its place; some could be omitted for 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 complexity (four standards, multiple parameters, nested object, output schema), the description covers most necessary context: standards definitions, example call, default values, companion tool, and deliverable options. Minor gaps: no mention of how standards selection changes output format or what happens with invalid deliverables. Still, overall 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 only 25%, but the description compensates by explaining the params object in detail, including defaults for use, jointing, material, and geometric parameters. It provides example values and clarifies the role of 'use' (only affects description text). This goes well beyond the bare 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 it is a 'Linear carrier-pipe measurement assembly' for computing BoQ across four standards, with specific details on materials, depth bands, and variants. It distinguishes itself from sibling tools by mentioning the free-tier alternative compute_manhole and companion assembly connection_to_existing.

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?

Explicitly states 'Paid tier only' and provides a direct alternative (compute_manhole) for free tier, along with a sign-up URL. Also mentions companion tool and example usage, giving clear when-to-use and when-not-to-use guidance.

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?

The description discloses authentication requirements (paid tier, TIER_INSUFFICIENT error), deliverable formats (xlsx, dxf, pdf), and that omitted parameters use defaults. It also mentions catalogue-driven sizing. The readOnlyHint annotation is true, and the description does not contradict it (computing and returning files is read-only). The description adds behavioral context beyond the annotations.

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 relatively long but well-structured with critical info front-loaded (paid tier, alternative, purpose). It includes an example call and lists deliverable options. Every sentence adds necessary context for civil engineering users. Minor redundancy (e.g., repeating standards in different forms) but overall efficient.

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 (many parameters, multiple standards, output deliverables, tier system), the description is comprehensive. It covers authentication, tier choice, standard selection, catalogue sizing, defaults, and deliverable generation. The output schema exists, so return values are not fully detailed but referenced. Sibling comparisons are made (manhole).

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has many parameters with some descriptions (25% coverage). The description adds value by explaining catalogue-driven sizing (size parameter picks from catalogue) and stating that omitted parameters use sensible defaults. It also provides example values for a few key parameters. However, detailed parameter meaning is mostly left to the 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 clearly states it 'Computes Precast Concrete Catchpit / Silt Trap BoQ' with specific standards (CESMM4, NRM2, MMHW, SMM7) and distinguishes from manholes by 'silt-sump-below-channel geometry'. The verb 'compute' plus the specific resource 'catchpit/silt trap' makes the purpose unambiguous, and it explicitly differentiates from sibling tool 'compute_manhole'.

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 usage context: it is a paid tier tool, with a free-tier alternative 'compute_manhole' mentioned. It explains typical positioning upstream of petrol/oil interceptor and gives example parameters and calls. However, it does not explicitly exclude other scenarios or provide a comprehensive 'when to use vs. not use' list beyond the manhole comparison.

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?

The description adds context beyond the readOnlyHint annotation by detailing authentication requirements (returns TIER_INSUFFICIENT), default parameter behavior, and the generation of temporary download URLs. It does not contradict the annotation and provides a clear picture of what the tool does.

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 well-structured: it front-loads the paid-tier warning, then describes the purpose, example parameters, an example call, and final notes on deliverables. Every sentence adds value without redundancy.

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 with nested objects and multiple standards, the description covers authentication, defaults, deliverables, and example usage. The output schema exists, so return values are assumed to be documented elsewhere, making this description 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?

Despite 0% schema_description_coverage, the description extensively explains key parameters (trench_length_m, service_spacing_mm, working_space_below_bed_mm) with examples and defaults. It covers complex nested parameters like services, providing semantics for all major 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 states it computes a BoQ for a combined services trench, specifying it handles multiple utilities per NJUG Volume 1 and renders through multiple measurement standards. It distinguishes itself from siblings by mentioning the free-tier alternative compute_manhole and implying it is for shared trenches.

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 explicitly mentions it is paid tier only and provides a free alternative. It includes an example call and explains deliverables, but does not explicitly state when to use this tool over other compute_ tools, though context makes it clear.

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?

Discloses paid tier, error behavior, deliverables, and standards mapping. However, the description mentions 'Opens the new drainage_ancillaries L2 leaf', which contradicts the readOnlyHint=true annotation (suggesting side effects). This inconsistency reduces transparency.

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 informative and well-structured, starting with critical usage warning, then function, standards, example, and deliverables. While slightly lengthy, all content earns its place; no waste. Could be slightly tighter but remains clear.

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 (4 params, nested objects, many siblings, output schema existence), the description covers purpose, usage, parameters, standards mapping, error conditions, and output formats. It is fully adequate for an AI agent to select and invoke 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 coverage is low (25%), but the description explains the discriminator logic (connection_type), bore digit suffix, and example parameters. It clarifies the role of 'method' vs 'connection_type' and notes defaults, adding significant meaning 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 states the tool computes extra-over connections for drainage pipes into existing assets, listing types and standards. It distinguishes from siblings like compute_manhole and carrier_pipe_run, making purpose immediately 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?

Explicitly warns about paid tier and provides alternative free tier (compute_manhole). Mentions sibling assembly carrier_pipe_run for complete line. Gives example call and parameter defaults, offering clear when-to-use and when-not-to-use guidance.

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?

Describes tier restriction, authentication requirement, default behaviors, output options (deliverables). Annotations declare readOnlyHint=true, which aligns with a compute tool. Adds value beyond annotations with tier and default details.

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?

Well-structured and comprehensive without excess. Each sentence contributes: tier info, purpose, standards, example, parameter descriptions. No redundancy.

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 complexity (many parameters, variants, outputs), the description provides a good overview, including presets and standards. It misses some parameter details but overall equips an agent to call 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 has low description coverage (20%), but the description adds meaning for key parameters (stem_height, curtain_thickness, toe_length, freeboard) and explains enums like counterfort_shape. Not all 30+ parameters are covered, but examples and defaults help.

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 explicitly states the tool computes a BoQ for an in-situ RC counterfort retaining wall, including variants and standards. It distinguishes from siblings like compute_cantilever_wall by specifying height ranges and tier differences.

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?

Provides clear guidance: paid tier only, alternative free tier compute_cantilever_wall, height range where counterfort wall is economic (4-10m). Also mentions example calls and parameter constraints.

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?

Annotations include readOnlyHint=true. The description adds behavior context: authentication requirements and error response for free users. No contradiction with annotations. It does not fully disclose all behaviors (e.g., rate limits) but provides key additional info.

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 quite long and includes many specifics (standards, presets, discriminator pattern). While informative, it could be more concise. However, it is well-structured with logical flow.

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 (multiple standards, lining types, deliverables, tier restrictions), the description covers all essential aspects. Output schema exists, and description mentions deliverables and output modes, making it 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 25%, but the description significantly adds meaning: explains geometry, defaults, and provides example parameter values. It compensates for low schema coverage with detailed explanation.

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 computes BoQ for open ditches, specifying verb 'Compute' and resource 'Open Ditch BoQ'. It distinguishes from sibling tools like 'compute_manhole' and details cross-section, lining variants, and standards.

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 states paid tier requirement and suggests free alternative 'compute_manhole'. Example parameters and call are provided. However, it does not explicitly list all scenarios where this tool should not be used.

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?

Annotations already indicate readOnlyHint=true, so the tool is read-only. The description adds that it requires authentication (paid tier) and returns TIER_INSUFFICIENT otherwise, and describes deliverables (xlsx, dxf, pdf) with watermarking on free tier. This context is valuable but does not significantly expand on behavioral traits beyond the annotation.

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 block of text that is moderately long. It front-loads the paid-tier warning and includes an example call, but the structure is dense and could be more scannable with bullet points or sections. Some details (e.g., 'Headline standard mapping') may be unnecessary for tool selection.

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 (many parameters, output modes, deliverables), the description covers the main purpose and some behavioral details (paid tier, deliverables) but does not explain the output schema or fully describe parameter semantics. It provides domain references (HD 33/16, HA 40/01) but remains incomplete for an unfamiliar agent.

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?

With 0% schema description coverage, the description must compensate. It provides example values and ranges for three parameters (pipe_internal_diameter_mm, pipe_wall_thickness_mm, drain_length) and mentions defaults for omitted parameters. However, it does not explain the meaning or purpose of the many other parameters, leaving significant gaps.

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 computes a BoQ for highway pavement edge drain per HD 33/16, with specific components (perforated carrier, granular-filled trench, geotextile wrap). It uses a specific verb ('compute') and resource, and distinguishes from siblings like compute_french_drain and compute_highway_drainage_channel.

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 explicitly marks the tool as paid tier only and provides a free-tier alternative (compute_manhole). It also suggests 'Omitted parameters use sensible engineering defaults' and gives an example call, but does not elaborate on when to choose this tool over other drain or drainage 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?

Annotations provide readOnlyHint=true. Description adds context about tier restrictions, computational delegation, and deliverable generation (watermarked free vs paid), which is useful beyond the annotation.

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?

Description is dense but front-loaded with critical info (tier requirement, alternative), followed by technical details and example; every sentence serves a purpose with no redundancy.

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?

Covers inputs (geometry, materials), processing (delegation to end_area_earthworks), outputs (CrossSection, mass-haul, deliverables), and constraints (paid tier, standards); example call and parameter ranges make it self-contained.

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 has 25% coverage; description compensates by providing realistic ranges and defaults for key parameters like crest_width_m, side_slope_h_per_v, strip_envelope_offset_m, and explains the height_profile purpose.

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 computes embankment cross-section BoQ using geometry inputs, and distinguishes it from the sibling tool compute_end_area_earthworks as a paid-tier alternative with explicit differences.

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?

Explicitly states paid-tier requirement, provides free-tier alternative, includes example parameters and call, and notes omitted parameters use sensible defaults, giving clear when-to-use and when-not-to-use guidance.

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?

Discloses computation methods (Simpson's Rule, trapezoidal fallback), SHW class tagging, mass-haul diagramming, and deliverable generation. The readOnlyHint annotation is not contradicted, and the description adds substantial behavioral context beyond annotations.

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 verbose and mixes pricing, technical details, and examples without clear structure. It is front-loaded with important tier info but overall could be more concise and better organized.

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?

Covers tier constraints, supported standards, computation method, outputs, and deliverables. With an existing output schema and annotations, the description provides sufficient context for selecting and invoking the tool, though it could elaborate on parameters like output_mode and standard.

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?

Adds meaning for a few parameters via example values (unacceptable_proportion, topsoil_strip_depth_m, topsoil_replace_depth_mm), but given only 25% schema description coverage, more parameter details in the description would be beneficial.

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 it computes end-area earthworks quantities following specific standards (MMHW etc.) and details features like mass-haul diagram and cut/fill balance. However, it is cluttered with pricing and tier information that muddy the core purpose.

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?

Provides usage guidance on free vs paid tiers and that anonymous callers are welcome, but does not explicitly state when to use this tool over sibling tools (which are clearly different structures) or when not to use it.

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?

The description describes generating BoQ and deliverables (xlsx, dxf, pdf) with download URLs, implying side effects (file creation on server). This contradicts the annotation readOnlyHint: true, which marks the tool as read-only. The description does not reconcile this contradiction, leading to a score of 1 with annotation contradiction flagged.

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 long but each sentence adds value: paid-tier warning, build-up composition, routing details, traffic categories, standards, example params, deliverables. It is front-loaded with the tier info, and while dense, it avoids repetition. Could be slightly tighter but earns a 4.

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 (many parameters, standards, traffic categories, deliverables), the description covers the main functionality and key constraints. It explains output modes and that omitted parameters use defaults. The output schema exists, so return values are covered. However, it lacks details on the exact response structure for different output modes, which slightly reduces 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 only 25%, so the description must compensate. It adds meaning by providing example parameters with ranges (length 0.5–2000, width 0.5–30, sub_base_thickness 100–500) and explaining the traffic_category defaults and mapping. However, many parameters (e.g., base_material, binder_material, capping_class) are not mentioned in the description, limiting compensation.

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 computes flexible pavement build-up BoQ, details the layers (capping, sub-base, base, binder, surface) and standards (CESMM4, NRM2, MMHW, SMM7). It differentiates from the free-tier alternative compute_end_area_earthworks and implies differentiation from sibling pavement tools like compute_rigid_pavement through the specific focus on bituminous pavement.

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 explicitly states the paid-tier requirement and suggests the free alternative compute_end_area_earthworks for users without an account. It also warns that for traffic >30 msa a full DMRB CD 226 design is needed, providing a 'when not to use' guideline. However, it could more directly contrast with other pavement tools like compute_rigid_pavement.

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?

The description discloses important behavioral traits: paid tier restriction with specific error message, free-tier alternative, defaults for omitted parameters, and one-shot download URLs for deliverables. It also mentions the standards supported. Even though annotations set readOnlyHint=true, the description adds significant context about side effects (generating files) and authorization needs. No contradiction with annotations.

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 well-structured with clear sections: tier info, technical description, example, and deliverable options. It is somewhat lengthy but every sentence provides valuable context. The front-loading of the paid-tier warning and alternative is effective. Minor reduction possible but overall efficient.

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 complexity of the tool (many parameters, nested objects, output schema exists), the description covers all essential aspects: purpose, tier restrictions, default behavior, example call, standards, and deliverable options. The output schema exists so return values are not needed in description. The tool's functionality is fully contextualized for correct selection and 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?

The schema description coverage is 0%, so the description must compensate. However, the description only provides example values and ranges for three parameters (pipe_internal_diameter_mm, pipe_wall_thickness_mm, drain_length), ignoring the other 14+ parameters in the schema. While the schema itself contains some descriptions for pipe_type and bedding_context, the description fails to add semantic meaning for most parameters. This is insufficient for a complex tool.

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 defines the tool's purpose: computing a French (filter) drain BoQ. It specifies the verb 'compute', the resource 'French drain BoQ', and distinguishes from the sibling 'compute_manhole' as a free-tier alternative. The description includes detailed technical context about the drain composition and supported standards, leaving no ambiguity.

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 explicitly states usage conditions: 'Paid tier only' and directs to sign up or use the free alternative 'compute_manhole'. It provides an example call with parameters and standard, and notes that omitted parameters use sensible defaults. It also explains optional deliverables like 'xlsx', 'dxf', 'pdf' and their tier restrictions. This gives clear guidance on when and how to use the 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?

The description reveals that the tool is a paid computation that returns deliverables (BoQ, DXF, PDF) and requires authentication. However, it does not explicitly contradict the readOnlyHint annotation; the description itself is transparent about behavior, but the annotation is misleading.

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 excessively long and contains verbose historical/technical details (e.g., discriminator pattern, work category entries, code references) that are not essential for invoking the tool. It could be significantly condensed.

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 complexity (nested params, variants, paid tier, multiple standards), the description is remarkably complete. It explains structural forms, code mappings, example calls, and deliverables. Output schema exists, so detailed return values are unnecessary.

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 low (25%), but the description adds meaning through example calls, defaults, and the explanation of deliverables. It provides context for the params object structure but does not systematically describe each parameter.

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 computes a BoQ for a gabion retaining wall, using specific verbs like 'Compute' and 'generate'. It distinguishes from siblings by naming the free-tier alternative compute_cantilever_wall and positions itself as the first non-concrete earth structure tool.

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?

Provides explicit when-to-use (modular gabion walls) and when-not-to (paid tier only, free tier alternative). Also mentions required authentication, example calls, and sensible defaults for omitted parameters.

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?

The annotations provide readOnlyHint: true, confirming no side effects. The description adds behavioral context about tier limitations and authentication requirements, but doesn't elaborate on potential errors, performance, or other traits beyond 'TIER_INSUFFICIENT' and sensible defaults.

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 long and contains both essential and extraneous details (e.g., internal pattern tracking). While front-loaded with key tier and alternative info, the later technical details could be trimmed for conciseness.

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?

Despite high complexity (many parameters, nested object, output schema), the description covers purpose, tier, alternatives, example usage, and deliverables. The output schema exists, so return values need not be described. Minor gap: no explicit list of presets or additional usage constraints.

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 25%, so the description should compensate. It provides example parameter values with ranges (e.g., stem_height 1.5–6) and mentions sensible defaults, adding some meaning beyond the schema. However, most parameters are not explained 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 clearly states that the tool computes a Bill of Quantities for a mass concrete gravity retaining wall. It mentions specific wall types (landscape, highway boundary, etc.) and distinguishes from sibling tool compute_cantilever_wall by noting it as a free-tier 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?

The description explicitly says this is a paid-tier tool and provides the alternative compute_cantilever_wall for free-tier usage. It includes example parameters and a sample call, giving clear guidance on when and how to use it.

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?

Annotations declare readOnlyHint=true, which is consistent with a computation that does not mutate state. The description adds behavioral details: free tier limitations, default parameters, example values, and deliverable generation (watermarked free).

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 comprehensive yet well-organized: tier info, component details, example, and deliverables. It is front-loaded with key facts. Minor redundancy (e.g., repeating standard names) could be trimmed.

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 complex nested parameters and presence of an output schema (not shown), the description covers main aspects: standards, component breakdown, example, and output options. It does not explain every parameter in depth but defaults are stated.

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%, but the description compensates with example parameters, ranges, and a sample call. It adds meaning beyond the schema by illustrating typical values and explaining defaults.

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 computes a highway/curtilage gully with connection BoQ, mentions standards and components, and includes an example. It distinguishes from siblings by focusing on a specific drainage inlet type.

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 specifies free vs paid tiers, which standards are available, and provides example calls. It implies when to use (e.g., for MMHW standard on free tier) but does not explicitly contrast with sibling tools or state when not to use.

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?

Goes beyond the readOnlyHint annotation by disclosing tier restriction, authentication requirement, error response, dual-quantity WorkItem behavior, eight variant presets, SMM7 handler's zero-priceable line, and one-shot download URLs for deliverables. Provides engineering context on geometry interpretation.

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 thorough but somewhat lengthy (5 paragraphs). The most critical information (purpose, tier, alternative) is front-loaded, but the latter paragraphs contain detailed engineering notes that could be condensed without losing 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 (dual quantity, multiple standards, presets, deliverables) and the annotation coverage (only readOnlyHint), the description provides comprehensive context. It explains edge cases (SMM7 deemed-included annotation pattern), output modes, and validation ranges for parameters.

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?

Adds extensive meaning beyond the input schema: explains geometry interpretation, volume calculation, depth banding, and the role of each parameter. Provides example values and emphasizes sensible defaults. Despite low schema description coverage (25%), the tool description compensates 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?

Description clearly states it performs linear extra-over measurement of hard material in drainage trench excavation. It specifies the dual-quantity nature (length and volume) and lists the relevant standards. Distinguishes from siblings by naming sibling assemblies and noting it closes the drainage_ancillaries L2 leaf.

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?

Explicitly mentions it is paid tier only and provides a free-tier alternative (compute_manhole). Includes example parameters and call. However, does not exhaustively compare to all sibling tools or give when-not-to-use scenarios.

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?

Describes rendering, tier restrictions, and download URLs, adding value beyond the readOnlyHint annotation. No contradiction, and details match the read-only behavior.

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?

Front-loaded with key info and well-structured, but slightly verbose with some redundancy.

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?

Covers main deliverables, tiers, and example call. Lack of output schema description is mitigated by description of return types.

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?

With 0% schema coverage, the description provides example params and ranges but does not describe all 30+ parameters. Helpful but not comprehensive.

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 it computes a reinforced concrete outfall headwall BoQ, specifying components and standards. However, it does not explicitly differentiate from sibling tools like compute_headwall_precast, which specializes in precast only.

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?

Clearly indicates free tier renders MMHW only and paid tier required for other standards, and provides example call. But does not explicitly state when to use this over 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?

The description discloses important behaviors beyond annotations: paid tier authentication (TIER_INSUFFICIENT), pattern usage, component composition, default supply route as PC emitter, and scour protection variants. No contradiction with 'readOnlyHint' annotation as the tool computes output without side effects.

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 verbose with dense technical details (e.g., '2nd use of the bundle-with-shared-envelope pattern') that may not be essential for tool selection. While informative, it could be more streamlined for an AI 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?

Given the tool's complexity (many parameters, nested objects, output schema), the description covers key aspects: deliverables, example call, defaults, and commercial context. It leverages the presence of an output schema to avoid detailing return values.

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 (25%), and the description adds meaning for some key parameters like orifice_diameter_mm and orifice_target_discharge_ls with examples and ranges. However, it does not explain all parameters comprehensively, relying partly on 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 clearly states it computes a headwall attenuation outlet BoQ, including precast concrete headwall, outlet-control ironmongery, and scour protection. It distinguishes from the sibling 'compute_headwall' by specifying paid tier and additional components.

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 mentions it's paid tier only, provides a free-tier alternative, gives example parameters and a sample call. However, it lacks explicit guidance on when to use this tool versus other headwall siblings like 'compute_headwall_precast'.

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?

The description details what the tool does (compute and return data) and the calculation standards used. Annotations provide readOnlyHint=true, and the description does not contradict; it adds context about tier restrictions and output formats.

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 detailed but somewhat verbose; it could be more concise. However, it is well-structured with front-loaded key information and examples.

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 complexity (nested parameters, multiple output options) and the presence of an output schema, the description covers purpose, usage, examples, and output possibilities adequately.

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 description provides example parameters with ranges, explains catalogue-driven sizing, and clarifies that omitted parameters use defaults. This adds value beyond the schema, which has 25% description 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 clearly states it computes a BoQ for precast concrete outfall headwalls, and distinguishes from the sibling 'compute_headwall' by specifying it as a paid-tier alternative with additional capabilities.

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?

Explicitly states 'Paid tier only' and provides an alternative free-tier tool (compute_headwall), along with authentication requirements and a URL for sign-up.

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?

The description claims it computes a BoQ and requires a paid tier, which implies a write or computational action. However, the annotations include readOnlyHint: true, a direct contradiction. This undermines transparency about whether the tool mutates data or is read-only. The description does not acknowledge or resolve this inconsistency.

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 very long and includes extensive technical detail, which is appropriate for a complex tool. However, it could be more concise by focusing on essential guidance and moving some background to references. It is front-loaded with tier and purpose 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?

Given the tool's complexity (many parameters, nested objects, multiple standards), the description is thorough. It explains channel types, depth classifications, outfall and silt box variants, deliverables, and gives example calls. It covers all necessary aspects for selection and 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?

Despite only 25% schema description coverage, the tool description adds substantial meaning to parameters. It explains each channel_type enum with UK practice, outfall and silt box types with detailed context, and provides example values and ranges. This compensates well for the schema gaps.

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 computes a highway drainage channel BoQ per specific UK standards (BS EN 1433, SHW Cl. 511-514, HD 33/16). It distinguishes from sibling tools by mentioning the free-tier alternative compute_end_area_earthworks. The verb 'compute' and resource 'highway drainage channel BoQ' are specific and 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 description explicitly states it is paid tier only and provides a free alternative. It gives example calls and parameter hints. However, it does not explicitly exclude other use cases or provide detailed when-not-to-use guidance beyond the free tier mention.

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?

Description discloses paid-tier behavior, error conditions, default behaviors, and one-shot download URLs for deliverables. Annotations provide readOnlyHint=true, which is consistent with a computation returning results. No contradictions. Some additional details like rate limits or response size are missing, but overall transparent.

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 relatively long but well-structured: starts with the paid-tier warning, then the core functionality, supported standards, example call, and deliverables. It's informative but could be trimmed by removing some redundant details (e.g., full list of profiles). Still, it's functional and 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?

For a complex tool with nested parameters, multiple standards, and deliverables, the description covers the essential aspects: what it computes, input examples, paid-tier caveat, and output options. It doesn't explain every combination or edge case, but it provides enough context for an AI agent to use the tool effectively, especially given the existence of an output schema.

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?

With only 25% schema description coverage, the description adds significant value by explaining kerb profiles (HB2, etc.) and channel types, providing example params with ranges (e.g., kerb_length: 1–1000, bed_thickness_mm: 75–300), and clarifying defaults. Not every parameter is covered, but the most important ones are, and the nested params object context is helpful.

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 computes a linear precast concrete kerb run BoQ, listing all emitted items (excavation, sub-base, concrete bed, kerb units, etc.) and supported standards. It distinguishes itself from siblings by specifying it's a paid-tier alternative to compute_cantilever_wall.

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?

Explicitly states the paid-tier requirement and the error code return for unauthorized calls, provides a free-tier alternative, gives a concrete example with parameters, and notes that omitted parameters use sensible defaults. This gives clear guidance on when and how to use the 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?

Discloses that unpaid calls return TIER_INSUFFICIENT, free-tier watermarks Excel, and PDF/dxf are paid. Annotations declare readOnlyHint=true, consistent with description. No contradiction.

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 verbose with technical details like internal banded grid codes. It could be more concise for agent consumption. The example is helpful but the overall length reduces 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 (many parameters, nested objects, output schema), the description covers purpose, constraints, and deliverables. Lacks some detail on return values but output schema exists.

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?

While schema coverage is low, the description adds context by summarizing discriminators and providing example parameters with ranges. The schema itself has extensive detail for each enum, so the description complements rather than repeats.

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 it computes a Bill of Quantities for lighting columns per standards. It distinguishes from siblings by mentioning it's the third 2D-banded handler with the largest grid and contrasts with the free-tier alternative compute_end_area_earthworks.

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?

Explicitly says 'Paid tier only' and directs to sign up or use free-tier alternative. Provides example call, mentions sensible defaults, and describes deliverables behavior. Clearly guides when and how to use.

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?

The description provides behavioral context beyond the readOnlyHint annotation, explaining the free tier watermarking, default engineering defaults, composite assembly details, and options for deliverables (xlsx, dxf, pdf). No contradictions with annotations.

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 structured with key information front-loaded (free tier, standard) and includes example params and call. It is somewhat lengthy but each sentence adds value, covering assembly, parameters, and optional outputs.

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 complex input schema (4 top-level params, many sub-params), existing output schema, and annotations, the description is complete: it explains the composite assembly, parameter defaults, supported standards, and deliverables. An agent can understand what the tool does and how 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%, but the description adds value by explaining key parameters (e.g., internal_diameter range 1–3 m, wall_thickness 0.1–0.25 m), the role of the standard, output_mode, and deliverables. It also gives an example call. However, not all parameters are explained, so the description partially compensates for the lack of 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 title 'Compute Precast Concrete Circular Manhole BoQ' and description clearly state the tool's purpose: computing the Bill of Quantities for a precast concrete circular manhole assembly. It distinguishes from siblings like compute_catchpit by specifying the exact composite assembly components (base slab, chamber rings, etc.) and supported excavation types.

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 clearly states the free tier only renders the MMHW standard, while paid tiers support CESMM4, NRM2, SMM7. It welcomes anonymous callers and provides an example call. However, it does not explicitly compare to siblings or say when not to use this tool, leaving some ambiguity.

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?

Annotations declare readOnlyHint=true, and the description adds important behavioral context: paid tier returns TIER_INSUFFICIENT error without authentication, deliverables include Excel/DXF/PDF with tier-dependent access, and defaults for omitted parameters. No contradiction with annotations.

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 well-structured with sections for tier info, construction details, standards, examples, and deliverables. It is compact for the amount of information but could be slightly more concise by trimming redundant standards enumeration.

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 complexity (many parameters, nested objects, output schema exists), the description covers tier constraints, example usage, standards references, and deliverables. It is fairly complete, though reliance on the schema for param details is acceptable.

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 25%, but the description adds value by explaining catalogue-driven sizing (PMC_1200 to PMC_2400) and providing example parameters with ranges. However, it does not systematically describe all parameters, relying on the schema's own 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 clearly states it computes a Bill of Quantities for a precast concrete monolithic manhole, specifying the exact construction type and standards. It distinguishes from the sibling tool 'compute_manhole' by noting the paid tier and free-tier 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?

Explicitly states 'Paid tier only' and provides the free-tier alternative 'compute_manhole'. Includes example parameters and a full example call, guiding when to use this tool vs alternatives.

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?

Annotations already indicate read-only (readOnlyHint=true). Description adds behavior: each section consumes a daily slot, free tier restriction, and error handling for non-linear items—going beyond annotations.

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?

Single concise paragraph with front-loaded purpose and an example. Every sentence adds value; no fluff. Could be broken into list for scanability but effective.

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 output schema exists, return values are covered. Description covers purpose, usage, constraints (free tier, slot consumption), example, error case. Missing details on a few parameters but overall sufficient for an agent to use 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 has 0% description coverage, so description compensates partially. Explains sections (per-section lengths/geometry) and assembly_slug (must be sectioned assembly). Provides an example. But does not detail standard, deliverables, aggregate_boq, include_backup, etc.

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 it computes a combined BoQ per section for linear assemblies, and distinguishes from sibling tools by specifying sectioned assemblies like wall, kerb, drain, and noting non-linear items return INVALID_INPUT.

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?

Provides explicit use cases (wall, kerb, drain, barrier) and free tier limitation (MMHW only, each section consumes one daily slot). Does not explicitly name alternative tools but context is clear.

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?

Annotations declare readOnlyHint=true, and description adds important behavioral context: authentication requirements, error handling, and that deliverables trigger download URLs. No contradiction; description enhances transparency beyond annotations.

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?

Single dense paragraph, but front-loads critical paid-tier warning. No wasted sentences; includes example call and deliverables explanation. Slightly long but efficient.

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 complexity (many nested parameters, output schema exists), description covers authentication, defaults, example, and deliverables. Does not explain return values (output schema handles that) but adequately sets expectations for a parametric tool. Some param details missing but sufficient for selection.

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%, but description provides example parameter values with ranges (length=2 m (0.5–10), width=2 m (0.5–10), thickness=0.45 m (0.15–2)), explains defaults, and mentions deliverables. Does not cover all 20+ parameters individually but adds meaningful guidance for key ones.

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 clearly states it computes a BoQ for a single isolated reinforced concrete pad foundation with optional pedestal, specifying verb (compute) and resource (pad foundation BoQ). It distinguishes from siblings like compute_cantilever_wall and compute_strip_foundation by name and free-tier 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?

Explicitly states paid tier only, returns TIER_INSUFFICIENT without authenticated account, and recommends free-tier alternative compute_cantilever_wall. Provides clear when-to-use and alternative.

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?

The description provides extensive behavioral context beyond annotations: tier restriction, required authentication, error code, standards, discriminators, output formats, and defaults. It does not contradict the readOnlyHint annotation (the tool computes and returns data without modifying state).

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 overly verbose with internal platform details (e.g., 'SEVENTH 1D-banded handler', 'LAUNCH-COMPLETING 45TH ASSEMBLY') that are not essential for tool selection or invocation. It front-loads the critical tier and purpose info but wastes space on obscure references.

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 (multiple enums, nested params, standards, output formats), the description covers all necessary aspects: tier, error handling, standards, param explanations, example call, and deliverables. It even explains return values (BoQ, DXF, PDF) despite an output schema existing.

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?

Despite low schema description coverage (25%), the description thoroughly explains the enum parameters (parapet_type, transition_type, containment_level) with full details and examples. It clarifies defaults and optional parameters, adding significant meaning 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 explicitly states the tool computes a BoQ for bridge/structural-deck parapets per multiple UK standards. It distinguishes itself from sibling compute_ tools by specifying the resource (parapet) and context (bridge deck), and even mentions a free-tier alternative (compute_end_area_earthworks).

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 clearly indicates this is a paid-tier tool with a free alternative, and it outlines the standards and classifications relevant. However, it lacks explicit when-use/when-not-use guidance beyond the tier restriction, and the internal platform context (e.g., '45th assembly') is not helpful for an agent deciding when to use 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?

Annotations set readOnlyHint=true, and the description does not contradict that. It adds behavioral context: the compute tool emits outputs (excavation, layers, etc.), can return deliverables, and enforces tier authentication. No annotation contradiction.

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 lengthy and dense, containing many details (trade-boundary principle, discriminators) that may not be essential for the agent. However, critical info (paid tier, example) is front-loaded. Could be more concise.

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 (many parameters, nested objects, multiple standards), the description covers what it computes, the three surface types and infiltration systems, example call, and deliverables. The output schema exists, so return values are documented separately.

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 25% (low), but the description compensates by explaining the meaning of surface_type (mapped to CIRIA types), infiltration_system (drives inclusion of membrane/pipe), reservoir_thickness_mm range, and sensible defaults. Example call further clarifies usage.

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 it 'computes permeable pavement BoQ per CIRIA C753', listing three UK surface types and three infiltration regimes. It differentiates from siblings by naming the free-tier alternative compute_end_area_earthworks and numerous compute_ 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?

Explicitly states 'Paid tier only' and requires an authenticated account, with a clear alternative for free tier. Provides example parameters and a full example call, guiding when to use and what to expect.

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?

The description discloses tier restrictions (TIER_INSUFFICIENT error) and output behavior (watermarked Excel for free tier, DXF/PDF for paid). It also explains engineering derivation (oil storage per BS EN 858-2 cl. 4.3.6). The readOnlyHint annotation is not contradicted as the tool computes and returns data without modifying state.

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 lengthy but well-structured, starting with tier info, then standards, selection axes, engineering details, and examples. Each sentence adds value, though some technical details could be streamlined for brevity without losing 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?

For a complex tool with many parameters, nested objects, and output schema, the description is thorough. It covers standards, selection logic, parameter details, deliverables, and usage examples. The output_mode parameter and mention of deliverables provide sufficient context, making the description 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?

Despite only 25% schema description coverage, the description provides extensive parameter details: examples with defaults, explanations of NS ratings and their catchment area mappings, descriptions of interceptor_type and performance_class options, and supply route enum. This compensates fully, adding significant meaning 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 explicitly states the tool computes a BoQ for a prefabricated petrol/oil interceptor, referencing specific standards (BS EN 858-1, BS EN 858-2, SHW Cl. 519) and detailing the three selection axes (Class, Type, Nominal Size). It also distinguishes from sibling tool compute_manhole as a free-tier 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?

The description clearly indicates it is paid tier only, provides a free-tier alternative (compute_manhole), and gives context for when to use (hot-spot catchments draining to soakaway, watercourse, or foul sewer). It includes example parameters and an example call, guiding proper usage.

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?

Beyond the readOnlyHint annotation, the description reveals authentication requirements, tier restriction, and the calculation strategy (strategy pattern with standards). It also specifies deliverables (xlsx, dxf, pdf) and that emissions include trench excavation, bedding, surround, etc. No contradictions with annotations.

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 verbose, containing technical details that could be streamlined. It is front-loaded with the paid tier warning but includes a lengthy explanation of standards and strategy patterns that, while informative, may exceed optimal conciseness for quick agent comprehension.

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 (multiple standards, parameters, output modes, deliverables), the description covers core concepts, usage, and outputs. The presence of an output schema reduces the need to describe return values, but the description adequately addresses what the tool computes and produces.

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 description provides example parameters with ranges (e.g., pipe_internal_diameter_mm 100-1800) and an example call, adding value over the schema's descriptions. However, many parameters lack detailed explanation in the description, and the schema itself covers some but not all. With low schema coverage, the description partially compensates.

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 it computes pipe bedding and surround BoQ for linear pipe trenches with class-driven bedding and surround, referencing specific standards (Highway, Building). It distinguishes itself from the free-tier sibling 'compute_manhole'. The verb 'Compute' and resource 'Pipe Bedding and Surround BoQ' are specific and 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?

Explicitly states 'Paid tier only' and that unauthenticated calls return TIER_INSUFFICIENT, with a link to pricing. Provides a free-tier alternative (compute_manhole). Includes an example call and notes that omitted parameters use sensible defaults, guiding proper invocation.

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?

Beyond annotations (readOnlyHint=true), the description discloses authentication requirements, tier constraints, one-shot download URL behavior for deliverables, and technical details like CESMM4/NRM2 routing. No contradiction with annotations.

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 information-dense but runs long. It front-loads critical tier info and provides structured details. Could be more concise, but complexity justifies length.

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 (4 params, nested input, output schema exists), the description covers tier, alternatives, test methods, standards, units, example, and deliverables behavior. It is complete for an agent to select and invoke 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?

The description elaborates on test_method (four methods with sub-codes), gives example ranges for length_tested_m and diameter_mm, explains deliverables parameter. However, pipe_material is not explained in description, and standard/output_mode are only implicitly in example call. Schemas coverage is 25%, so description adds significant value but misses some parameters.

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 it computes linear measurement of testing on new drainage pipework, listing specific test methods and standards. It distinguishes from siblings by naming the free-tier alternative compute_manhole and positioning as third member of drainage_ancillaries leaf, with a unique discriminator pattern.

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?

Explicitly states 'Paid tier only', warns about TIER_INSUFFICIENT, directs to free alternative, and provides example params and call. It also notes omitted parameters use defaults, giving clear when-to-use and how-to-call guidance.

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?

Beyond the readOnlyHint annotation, it discloses authentication requirements (TIER_INSUFFICIENT error), output formats (Excel, DXF, PDF), and that free tier watermarks the Excel. It also explains the measurement basis and coding scheme, providing full context for safe use.

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 overly verbose and includes esoteric technical history (e.g., '17th use of the classed-then-legacy attribute discrimination pattern') that is not helpful for an AI agent. It could be front-loaded with essential info and trimmed significantly.

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?

Covers tier restriction, facing variants, standards, example calls, deliverables, and defaults. However, lacks a formal description of the return value structure (though output schema exists). For a complex tool with many options, it is fairly 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?

Despite low schema coverage (25%), the description compensates by explaining the params object as a dataclass with sensible defaults, providing example values and ranges for key parameters, and detailing the discriminator rsw_facing. The nested schema inside params has rich enum descriptions, adding semantic value.

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 it 'Compute Reinforced Soil Wall (RSW) BoQ' and lists four facing systems, measurement basis, and standards. It distinguishes from siblings by calling out the free-tier alternative compute_cantilever_wall and its position in the wall family hierarchy.

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?

Explicitly states it is paid tier and provides the free alternative. Gives example parameters and calls, plus the deliverable options. Tells when to use this tool vs compute_cantilever_wall.

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?

Discloses authentication requirement, paid tier, and free alternative. Explains computation process, standards, and deliverables. No contradiction with readOnlyHint annotation.

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?

Long but well-structured: starts with access requirement, then build-up, standards, defaults, example call, deliverables. Every sentence adds value; slight verbosity justified by 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?

Given complexity (20+ parameters, nested input, output schema exists), description covers purpose, inputs, defaults, standards, example, and deliverables. Sufficient 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 25% but schema itself contains detailed parameter descriptions. The description adds value by explaining overall defaults, example parameters, and engineering context beyond 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?

Clearly states it computes BoQ for rigid pavement build-up, listing components and standards. Distinguishes from compute_flexible_pavement and compute_end_area_earthworks, both siblings.

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?

Explicitly mentions paid tier, provides free alternative (compute_end_area_earthworks), gives example call and parameters, and indicates when to omit defaults.

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?

Annotations already mark the tool as readOnlyHint=true. The description adds authentication requirement (TIER_INSUFFICIENT error) and output delivery details, providing useful behavioral context beyond the annotation.

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 excessively long, mixing critical information (paid tier, alternative) with verbose technical details about assembly hierarchy and presets. It lacks front-loaded clarity, forcing an agent to parse dense text.

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?

Covers authentication, parameter defaults, output modes, and deliverables. While complete for a complex tool, the verbosity reduces quick comprehension; a more structured presentation would improve completeness perception.

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?

With only 25% schema coverage, the description thoroughly explains each parameter, including defaults, enums, and interpretation rules (e.g., line_length_m meaning, discrimination logic). This fully compensates for the sparse 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 clearly states the tool computes a BoQ for road markings, referencing UK standards. However, the purpose is somewhat buried among extensive secondary details about assembly lineage and presets, which could distract an agent.

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?

Explicitly states the paid tier requirement and points to a free alternative (compute_end_area_earthworks), giving clear guidance on when to use this tool vs. another.

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?

The description contradicts the annotation readOnlyHint=true. The tool clearly performs computation and generates deliverables (Excel, DXF, PDF), indicating it is not read-only. This inconsistency misleads the AI agent about the tool's behavioral traits.

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 detailed but efficient, front-loading critical usage information (paid tier, free alternative). While it is somewhat lengthy, the amount of technical detail is justified by the tool's complexity. Minor improvements could make it slightly more concise.

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, the description covers all necessary aspects: authentication requirements, output formats, example parameters, mapping to standards, and defaults. It provides enough context for the AI agent to use the tool correctly among 40+ sibling tools.

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?

Despite low schema description coverage (25%), the description adds substantial value by explaining the purpose of the params object, listing example parameters with ranges, describing enum options like service_type and bedding_context, and linking defaults to NJUG guidance. This fully compensates for the sparse 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 clearly identifies the tool as computing a single-service utility run per NJUG Volume 1 for specific utility types (water, gas, electricity, telecoms, etc.). It distinguishes from sibling tools by mentioning the free-tier alternative compute_manhole and implying it differs from compute_combined_services_trench.

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?

Explicitly states it is 'Paid tier only,' describes the tier error response, and directs users to a free alternative (compute_manhole). Provides example parameters and an example call, and explains that omitted parameters use sensible defaults.

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?

Discloses that the engine refuses to size for VERY_HIGH hot-spot catchments, and checks half-emptying time per C753. Annotations already indicate readOnlyHint=true, and description adds behavioral constraints beyond this.

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?

Well-structured with clear sections: paid tier warning, alternative, purpose, example, deliverables. Each sentence adds value and is front-loaded with essential info.

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 complexity and existence of output schema, the description covers purpose, parameters, limitations, example, and deliverables comprehensively.

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 low (25%), but the description explains key parameters (catchment_area, rainfall, infiltration rate) and provides two design storm methods. It adds context for hot_spot, confidence, and tank_type, though not all parameters are covered.

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 computes an infiltration soakaway BoQ per CIRIA C753, specifying the sizing engine, safety factors, and deliverables. It distinguishes itself from the sibling compute_attenuation_tank by noting it's the paid tier with infiltration discharge.

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?

Explicitly states paid tier requirement and provides alternative free-tier tool (compute_attenuation_tank). Includes example parameters and a sample call, giving clear guidance on when and how to use it.

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?

The description discloses that the tool requires an authenticated CivilQuants account and returns TIER_INSUFFICIENT error otherwise, and that deliverable URLs are returned for XLSX/DXF/PDF. This adds valuable context beyond the readOnlyHint annotation, though the annotation already signals no state mutation.

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 quite long and dense, with a single paragraph structure that could be better organized with bullet points or sections. While it is front-loaded with the paid-tier warning, the rest is a stream of technical details that may be overwhelming.

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, usage constraints (paid tier), parameter guidance, output options, and examples. Given the tool's complexity (multiple face systems, many parameters, output formats), the description is sufficiently complete, though it could be more structured.

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 description adds meaning beyond the schema by providing overall context (e.g., variant presets, coding standards, example calls) and summarizing parameter behavior. Although the input schema has detailed descriptions for enum parameters, the description's extra examples and hierarchy information enhance understanding.

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 it computes a BoQ for a soil-nailed slope, specifies the resource (soil-nailed slope) and action (compute BoQ), and distinguishes itself from sibling tools like compute_gabion_wall and compute_reinforced_soil_wall by noting it is the third member of the earth_structures leaf.

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 explicitly mentions that it is a paid-tier tool and provides a free-tier alternative (compute_cantilever_wall). It also gives context on when to choose each face system via the enum descriptions. However, it does not compare to other similar retaining wall tools beyond the leaf hierarchy.

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?

Annotations declare readOnlyHint=true, which is consistent with a computation tool. The description adds critical behavioral details: authentication requirement, error on insufficient tier, and that deliverables (xlsx, dxf, pdf) are generated with paid tier or watermarked for free. It also mentions integration with BS 8666:2020 and stepping as a demonstration of cross-cutting standards. No contradictions with annotations.

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 information-dense and well-structured, starting with the paid-tier warning and ending with deliverables. It contains some marketing language ('Closes the P1 launch set', 'v10 demonstration') that, while not harmful, could be trimmed for brevity. Overall, every sentence earns its place, but a slightly tighter version would be a 5.

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?

Despite having 4 top-level parameters and a nested object, the description and schema together fully describe the tool's behavior, inputs, outputs (including deliverables and formats), and constraints (paid tier, authentication). The existence of an output schema (not shown) further reduces burden. The description also ties it to standards (BS 8666, CESMM4, NRM2, etc.) and gives real-world context (UK domestic/light commercial defaults).

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 provides a detailed description for the 'params' object, explaining defaults and reinforcement details. The tool description supplements with explicit example values and ranges for key parameters (length=10 m [1-100], width=0.75 m [0.3-2.5], thickness=0.35 m [0.15-1.5]), and clarifies omitted parameters use sensible engineering defaults. This goes well beyond the schema alone.

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 computes a bill of quantities for a concrete strip foundation (linear reinforced, level or stepped). It distinguishes from sibling tools like compute_cantilever_wall (free-tier alternative) and pad_foundation (part of the same launch set). The verb 'compute' combined with the specific resource and variants makes the purpose 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?

Explicitly states 'Paid tier only' and provides a clear free-tier alternative (compute_cantilever_wall). Includes an example call and parameter ranges, explaining when to use this tool (linear reinforced strip foundation) and how to request deliverables. The guidelines are comprehensive and actionable.

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?

Discloses authentication requirement and tier error behavior, and describes all deliverables and output formats. Annotations have readOnlyHint=true, which is consistent with a computation tool that does not mutate data; no contradiction.

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?

Front-loaded with critical tier information, followed by concise technical description, examples, and deliverables. Each sentence adds value without redundancy.

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 (nested params, multiple outputs), the description covers all important aspects: tier, alternatives, parameter examples, and deliverables. Output schema exists, so return values are not needed in description.

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%, but the description provides detailed examples, defaults, and ranges for key parameters like bed_width and side slopes. It explains the overall params object but does not list every subparameter; still adds significant meaning 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 clearly states the tool computes a SuDS swale BoQ per CIRIA C753, with specific examples of parameters and a free-tier alternative. It distinguishes itself from siblings by explicitly naming compute_attenuation_tank.

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?

Explicitly states it is paid tier only and requires authentication, provides a free alternative, and gives example calls and parameter ranges. Clearly guides when to use and what to expect.

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?

Annotations indicate readOnlyHint=true, and the description confirms no side effects beyond computing outputs. It discloses authentication requirements, error condition (TIER_INSUFFICIENT), and deliverables behavior. No contradictions with annotations.

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 structured with bullet points, examples, and presets, making it readable. While lengthy, it front-loads critical info (paid tier, alternative). Some detailed codes (CESMM4, etc.) add noise but are relevant.

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 many parameters and options, the description covers sign types, presets, standards, and deliverables. However, it lacks explanation of the JSON response structure for output modes like 'summary' or 'full_json'. Output schema is absent, so description should cover this.

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 low (25%), but description adds extensive parameter guidance: example values, defaults, geometry interpretation, foundation types, and face area classes. This compensates well for missing 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 clearly states the tool computes a traffic sign Bill of Quantities per UK standards (SHW, TSRGD). It specifies the five sign types and mentions a free-tier alternative (compute_end_area_earthworks), distinguishing it from siblings.

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?

Explicitly states 'Paid tier only' and provides a free-tier alternative. Includes example calls and parameter guidance. However, it does not explicitly mention when not to use this tool versus other compute_* siblings besides the one alternative.

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?

The description reveals internal routing logic, default behaviors, and parameter constraints (e.g., example ranges). It mentions tier responses and download URL generation for deliverables. The readOnlyHint annotation suggests no side effects, which the description does not contradict. However, the exact return format is not fully described (though an output schema exists).

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 dense and packed with information but could be more concise. It front-loads the paid tier note and then lists types, standards, examples, and deliverables. While organized, it is longer than necessary for the core functionality.

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 complexity (many parameters, nested object, output schema), the description covers chamber types, standards, defaults, an example call, and deliverables. It does not elaborate on the output_mode enum, but the output schema exists. Overall, it provides sufficient context for a domain-literate user.

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 (25%), but the description adds meaning: it explains chamber_type enum values with UK types, supply routing defaults, and provides example parameter values and ranges. It does not explain every parameter (e.g., output_mode), so some burden remains on 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 the tool computes a Bill of Quantities for utility access chambers, listing ten specific UK chamber types and supporting four standards. It distinguishes itself from the sibling compute_manhole, which is noted as a free-tier 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?

The description explicitly notes the paid tier requirement and provides a free alternative (compute_manhole). It gives context on authentication (CivilQuants account) but does not explicitly state when to use this tool over other compute_* tools beyond the chamber specialization.

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?

The description adds important behavioral context beyond the readOnlyHint annotation: authentication requirements, tier-based access, default supply routes, and parameter defaults. However, it does not fully detail all defaults or error conditions.

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 informative but slightly verbose, containing domain-specific jargon. It is well-structured with a clear flow, but could be more concise without losing essential 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?

Given the tool's complexity and low schema coverage, the description provides a solid overview but lacks detailed documentation of all parameter combinations and edge cases. The presence of an output schema compensates partially, but more detail on return values (beyond deliverables) would 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?

With schema description coverage at only 25%, the description compensates by providing example parameters with units and ranges, explaining the kiosk_type enum, and describing supply_route defaults. This adds significant meaning beyond the schema's minimal 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 clearly states that this tool computes a Bill of Quantities (BoQ) for utility kiosk bases, covering substructure and hardware composite for five specific cabinet types. It also mentions it wraps 'pad_foundation' and can output deliverables (xlsx, dxf, pdf), which fully specifies the tool's purpose and distinguishes it from siblings like 'compute_manhole'.

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?

Explicitly states 'Paid tier only' and directs free-tier users to the alternative 'compute_manhole'. This provides clear guidance on when to use this tool versus an alternative.

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?

The description adds extensive behavioral context beyond the readOnlyHint annotation: it reveals the paid-tier limitation, authentication requirement, error response, system type discrimination, standard codes, and output deliverables. This fully informs the agent about the tool's behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded with critical information (paid tier, alternative) but is quite lengthy, spanning several paragraphs. While every sentence adds value, the verbosity could be trimmed without losing essential guidance.

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 (4 parameters, nested objects, output schema), the description is remarkably complete: it covers purpose, standards, variants, presets, example calls, parameter details, and output formats. No critical gaps remain for agent understanding.

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?

Despite low schema description coverage (25%), the description richly explains parameters in context, providing example values, ranges, and detailed enum descriptions (e.g., vrs_system_type with six variants). It adds meaning beyond the input schema, such as geometry interpretation and system-specific attributes.

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 ('compute') and resource ('Vehicle Restraint System BoQ'), clearly indicating the tool's function for highway works. It distinguishes itself from siblings by mentioning the free-tier alternative 'compute_end_area_earthworks' and detailing its role as the first member of the highway_restraint L2 leaf.

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 explicitly states the paid-tier requirement and directs users to sign up or use a free alternative. It provides clear context for when to use this tool (VRS BoQ for highway works) but does not explicitly list conditions where the tool should not be used, though the purpose is well-defined.

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?

Annotations already declare readOnlyHint=true, and the description reinforces this by stating 'obtain' and 'read the toolkit'. It discloses execution limitations, size of components, and the purpose of the parameter, adding context beyond annotations.

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 concise with 4 sentences, front-loaded with purpose. Each sentence is meaningful: defines the tool, lists return elements, notes universal availability, warns about execution restrictions, and explains the parameter.

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 parameter schema, good annotations, and presence of an output schema, the description covers all necessary context: what the tool returns, how to use the optional parameter, and behavioral constraints. No additional information is needed.

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 has 100% coverage with a description for the 'component' parameter. The description adds value by explaining the size implication (~20 KB vs ~60 KB) and clarifying usage of enum values, enhancing the schema's information.

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 retrieves the 'CivilQuants customer-side document pipeline' with specific verb and resource. It distinguishes from sibling tools (compute_*, get_project, etc.) by focusing on a pipeline toolkit for document-heavy skills.

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 explicitly notes that the pipeline cannot be executed in a chat connector but requires a code-execution client, providing clear usage boundaries. It implies when to fetch components via the 'component' parameter but doesn't enumerate alternatives to the tool itself.

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?

Beyond readOnlyHint annotation, it discloses error handling (envelope with candidate ids), fallback behavior (display name), and tier requirement.

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, front-loaded with main action, no fluff.

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 1 required param and output schema present, the description covers usage, edge cases, errors, and tier constraints completely.

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?

With 0% schema description coverage, the description fully explains the two modes of using project_id (id or display name) and the resolution of name conflicts.

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 verb 'fetch' and resource 'project by project_id', distinguishing it from sibling tools like list_projects which is for browsing all projects.

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?

Provides explicit when-to-use (fetch by id or display name), when-not-to (if multiple shares, use list_projects), and tier restriction (paid only).

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?

Goes well beyond readOnlyHint annotation by detailing tier-dependent responses (full methodology, TIER_INSUFFICIENT, INVALID_TOKEN), notes that CivilQuants does not run inference, and explains dependencies on get_document_pipeline.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded with key qualifier 'Paid tier only' and core function. It's a single paragraph but each sentence adds necessary context. Minor redundancy in tier details could be tightened.

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 (multiple response types, execution environment needs) and the presence of an output schema, the description covers all critical aspects: prerequisites, behavior, and integration with sibling tools.

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 baseline 3. Description adds an example skill slug and reinforces that it comes from list_skills, adding practical value beyond the schema's 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 states the verb 'fetch' and resource 'senior-QS skill methodology by slug', clearly distinguishing from sibling compute tools. It mentions list_skills for slugs and explains the returned body is for the AI to apply, avoiding ambiguity.

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?

Explicitly says 'Paid tier only', provides alternative list_skills for slugs, contrasts free vs paid responses, and advises on code-execution client vs chat connector for document-heavy skills.

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