civilquants

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

Annotations declare readOnlyHint: true, which is consistent with a read-only computation. The description adds transparency about authentication requirements and error behavior beyond the annotation. It does not mention side effects, and no contradiction 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 verbose and includes extensive standard code references and variant details. While structured, it could be more concise. Every sentence adds value but the length may hinder quick 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 complexity (many parameters, output schema exists), the description covers purpose, alternatives, variants, and standards. It could omit minor details like every standard code for each component, but overall it equips an agent to decide when and how to use the 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 only 50% (many parameters lack descriptions), and the tool description does not elaborate on parameter meaning. It focuses on variants and standards rather than clarifying individual parameters. This leaves the agent underinformed for parameter selection.

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 anchored retaining walls. It lists three structural variants (INSITU_RC, KING_POST, SHEET_PILED) and distinguishes itself from the sibling tool compute_cantilever_wall via the paid-tier and anchor-specific scope.

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 requirement and the TIER_INSUFFICIENT error, directly names the free-tier alternative compute_cantilever_wall. Also provides guidance on which variant to choose based on height and application (e.g., sheet piles for quays/cofferdams).

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; description adds 'Free tier. Anonymous callers welcome.', clarifying it's free and requires no auth, beyond annotation context.

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

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

Two sentences front-loaded with key context (free, anonymous) and essential technical details; no wasted words.

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 tool complexity and many siblings, description lacks guidance on parameter interplay and selection scenarios; output schema exists but does not compensate for missing usage context.

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%; description only hints at configurations (crate vs pipes) but does not explain individual parameters or their roles for the 20+ 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 'Compute Stormwater Attenuation Tank BoQ' with specific verb 'compute' and resource, and distinguishes from siblings by mentioning two configurations and 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 implies use for stormwater attenuation tank BoQ but lacks explicit when-to-use vs alternatives, and does not advise on selecting configurations or excavation methods.

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, description discloses paywall behavior and required authentication. Details four structural forms, measurement codes, and variant presets, enriching understanding of how the tool operates and what it produces.

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 detailed but somewhat verbose with enumerations and codes. It front-loads the critical paywall and alternative info. Could be trimmed without losing essential guidance, but structure is logical.

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 objects, enums, presets), the description covers usage context, authentication, structural forms, measurement standards, and variant presets. With an existing output schema, this is fully adequate for agent decision-making.

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 50%, and the description provides an overview of the params object, explaining the discriminators and defaults. This adds context that helps interpret parameter combinations, though individual parameter details rely 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 BoQ for a bored pile retaining wall, specifying cast-in-place bored concrete pile. It distinguishes from siblings by mentioning free-tier alternative compute_cantilever_wall and placing it as the seventh member of the wall family.

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 warns about TIER_INSUFFICIENT error without authentication. Provides clear alternative: free-tier compute_cantilever_wall. This gives strong 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?

Annotations mark readOnlyHint: true, and the description does not contradict this (it says 'compute', implying read-only calculation). The description adds behavioral context about authentication requirements and paid-tier restriction, but does not explicitly state that no state is modified.

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 well-structured, starting with the most critical usage restriction (paid tier) and then the alternative. While verbose, each sentence serves a purpose, covering the tool's scope, composition, and standards. Minor redundancy 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 tool's complexity (nested params, 2 top-level parameters), the description provides a good overview of what the computation includes (precast units, blinding, bedding, geotextile, etc.). With an output schema present, it does not need to detail return values. The description covers constraints and alternatives 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 input schema already provides rich descriptions for nested parameters (e.g., size enum with size explanations). The description adds additional meaning beyond the schema, including product ranges, standards, and the overall composition of the BoQ. With high schema coverage, the description still adds 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 computes a BoQ for a precast concrete box culvert run, specifying brands (Marshalls/FP McCann/CPM), standards (BS EN 14844/BS 5911-3), and catalogue sizes. It distinguishes from sibling tool compute_manhole by explicitly mentioning the 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 states 'Paid tier only' and that unauthenticated calls return TIER_INSUFFICIENT, providing clear when-to-use guidance. It also names the free alternative compute_manhole, helping agents decide between 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 already provide readOnlyHint=true, so the description adds marginal value by stating 'Free tier. Anonymous callers welcome.' It does not disclose any additional behavioral traits like rate limits or data handling. 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 concise (three sentences) and front-loaded with the main function. However, the first sentence about free tier could be integrated or placed after the core description for better structure.

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 complexity (18 parameters), the description is too sparse. It does not explain units, parameter relationships, or expected values. While an output schema exists, the lack of parameter context makes the tool hard to use correctly without external knowledge.

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 for the nested params object (18 parameters), the description fails to explain parameters like toe_length, backfill_class, or reinforcement_kg_per_m3. The agent has no semantics beyond parameter names and defaults, severely hindering correct invocation.

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 specifies the tool computes a Bill of Quantities for an in-situ reinforced concrete cantilever retaining wall, listing key components (toe, heel, stem) and included items (excavation, blinding, drainage, backfill). This distinguishes it from sibling wall types like gravity or anchored walls.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives no guidance on when to choose this tool over alternatives such as compute_gravity_wall or compute_anchored_wall. No prerequisites or conditions are mentioned, leaving the agent to guess based on the wall type name alone.

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

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

The description explicitly notes the paid-tier restriction and the error response TIER_INSUFFICIENT, which adds critical behavioral context beyond the readOnlyHint annotation. No contradictions with annotations are present.

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

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

The description is excessively long (4 paragraphs) and includes tangential details like variant presets and discrimination patterns. It could be trimmed to focus on essential information 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?

The description covers the paid-tier limitation and the combination of four standards, but does not clearly state the tool's output (a set of BoQ rows) even though an output schema exists. For a complex tool with nested parameters, more clarity on return format 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 description adds semantic context for parameters (e.g., material sub-class digits, depth bands) beyond the schema's descriptions, which have 50% coverage. However, not all parameters are covered, and the added info is scattered rather than structured per 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 BoQ for carrier pipe runs with four standards (CESMM4, NRM2, MMHW, SMM7) and distinguishes it from the companion tool compute_connection_to_existing. However, it is verbose and mixes implementation details like the 19th discrimination pattern, which slightly obscures 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?

The description mentions a free-tier alternative (compute_manhole) and a companion assembly (connection_to_existing), but does not give explicit guidance on when to use this tool versus its siblings. There is no clear 'when-to-use' or 'when-not-to-use' statement.

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 declare readOnlyHint=true, which the description reinforces by indicating the tool computes a BoQ without mutating state. The description adds behavioral context beyond annotations: the tier restriction, authentication requirement, and the return of a TIER_INSUFFICIENT error. However, since annotations already cover the read-only nature, the description's added value is moderate.

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 fairly long (multiple paragraphs) but each sentence contributes value—purpose, tier restriction, alternative, typical use, and construction details. It is front-loaded with critical tier info. While verbose, it remains structured and relevant. Could be tightened 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 (many parameters, catalogue-driven, multiple standards), the description covers all important aspects: what it does, limitations, alternative, typical drainage context, standards used, and relationship to manholes. An output schema exists, so return values are covered elsewhere. The description is complete for an agent to select and invoke this 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?

The input schema has 50% description coverage; the main description mentions catalogue-driven sizing and override capability, but does not detail individual parameters. It adds minimal semantic context beyond the schema's own descriptions, which are present for some parameters. The description compensates partially by explaining the structure and the catalogue, but not extensively.

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 precast concrete catchpit/silt trap, specifies the resource (catchpit) and action (compute), and explicitly distinguishes it from the sibling 'compute_manhole' by detailing the silt-sump geometry and typical drainage position. The verb 'Compute' and resource 'Catchpit' are specific and unique among 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?

The description provides explicit usage guidance: it is paid-tier only, requires an authenticated CivilQuants account, and directs users to the free-tier alternative 'compute_manhole' if unauthorized. It also gives contextual usage information (upstream of interceptor in forecourt/service area), making when-to-use and when-not-to-use very 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 already indicate read-only (readOnlyHint: true). The description adds context about paid tier and error behavior but does not contradict annotations. It does not elaborate on other behavioral traits beyond what annotations cover.

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 four sentences, front-loaded with critical usage info (paid tier). It is relatively concise, though acronym-heavy. No wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With an output schema, the description does not need to explain return values. However, for a complex tool with many parameters and standards, more explanation of methodology and parameter relationships would be beneficial.

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

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

Schema description coverage is 0%, so the description should compensate but only provides a high-level overview of the trench model. Individual parameters are not explained, but some schema properties have their own descriptions. The description adds some context about services and standards.

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 combined services trench, specifying the services and standards. However, it does not clearly distinguish from sibling tools like compute_single_service_run; mentioning compute_manhole as a free alternative is misleading.

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 describes the error response for unauthenticated calls. Provides a free alternative (compute_manhole), though that alternative may not be functionally equivalent.

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 provide readOnlyHint=true. The description adds important behavioral context: it requires an authenticated account (paid tier), and describes that it enumerates standard-specific sub-codes based on connection_type. The phrase 'Opens the new drainage_ancillaries L2 leaf' implies output structure, consistent with readOnly operation. 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: tier restriction first, then purpose, standards, parameter guidance, and sibling reference. It is packed with information but each sentence adds value. Could be slightly more streamlined, but overall effective 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?

Given the complexity (multiple standards, sub-codes, nested parameters, output schema exists), the description covers essential context: tier limitation, what gets computed, the mapping of connection_type to standards, and relation to sibling tools. It does not detail output format but output schema exists, so not needed. Completeness is high.

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 two parameters with nested objects; only 50% schema description coverage. The main description explains the role of connection_type as a discriminator and the bore digit, adding meaning beyond the schema. However, it does not elaborate on other parameters like method or diameter_mm, leaving some gaps. Baseline 3 is appropriate as 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 the tool computes an extra-over connection item for a new drainage carrier pipe into an existing asset, referencing specific standards (CESMM4, etc.) and distinguishing from the free-tier sibling compute_manhole. The verb 'compute' and resource 'connection to existing' are specific and differentiated from many 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 when to use this tool (paid tier), and provides alternatives: compute_manhole for free tier. Also references sibling assembly carrier_pipe_run as the companion tool. However, does not list all other siblings or give exhaustive when-not-to-use scenarios, but the context is clear enough.

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

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

Annotations provide readOnlyHint=true, and the description adds that the tool requires paid authentication and returns TIER_INSUFFICIENT on failure. It also mentions variant presets and standards routing, giving 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 fairly long but well-structured, front-loading critical information (paid tier, alternative) before structural details and variant presets. Some jargon could be trimmed, but it's appropriate for the 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?

With an output schema present, the description does not need to detail return values. It provides enough domain context (height ranges, standards, presets) for an agent to select and invoke the tool appropriately.

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 50% description coverage, and the tool description adds overall context (e.g., 'includes base slab, thin curtain wall, counterforts at configurable centres') but does not explain the many individual parameters. The description of the 'params' object itself is in the schema, and the tool description mentions sensible defaults, providing baseline 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 the tool computes a BoQ for in-situ reinforced concrete counterfort retaining walls. It distinguishes from siblings by explicitly mentioning the free-tier alternative compute_cantilever_wall and providing height range context (4-10m, above cantilever-economic, below anchored-wall range).

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 requiring authentication, and directs users to the free-tier alternative compute_cantilever_wall. It also provides context on when the tool is appropriate (4-10m retained heights).

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 on paid-tier restriction, standard routing, and variant presets. No contradiction. Could be more explicit about being read-only, but overall adds 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?

Front-loaded with tier info and alternative, then detailed standards and variants. Somewhat verbose but structured coherently for specialized use.

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 purpose, tier restrictions, alternatives, geometry, lining variants, standards (with differences), discriminator pattern, and unit. Output schema exists; no need to describe return values. Complete for the tool's complexity.

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

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

Schema coverage is 50% with good descriptions for params and lining_type. The description adds context on geometry and lining types but mostly aligns with schema. Adequate but not exceptional.

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 it computes a BoQ for an open ditch, defines the cross-section, lining variants, standards, and unit (M). It distinguishes itself from siblings by mentioning compute_manhole as free-tier alternative and its position in the drainage_ancillaries 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?

Clearly states paid-tier requirement and directs free users to compute_manhole. Provides context on standards (CESMM4, NRM2, MMHW, SMM7) and the discriminator lining_type for variant 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?

Annotations provide readOnlyHint: true, which is consistent with a computation tool. The description adds behavioral context beyond annotations: paid-tier restriction, error message, and the need for authenticated account. It does not contradict annotations, and the additional disclosure about tier limitations increases 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 5 sentences long, front-loaded with the critical paid-tier warning. It includes technical jargon and standard references that may be dense but relevant. Some details (e.g., headline standard mapping) could be shortened, making it slightly less concise than ideal.

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 tool has many parameters (2 top-level, many nested) and an output schema (not shown). The description provides high-level context and standard mappings but fails to explain the parameters or the output structure. Given the complexity, this is incomplete for an agent to use effectively.

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% according to context, meaning no parameter descriptions exist in the schema. The description provides no explanations of individual parameters such as drain_length, invert_depth, or pipe_type. Without any parameter-level guidance, the agent cannot understand what values to provide or how they affect the computation, making this score very low.

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 highway pavement edge drain BoQ per HD 33/16, naming standard HD 33/16 and components (perforated carrier, granular-filled trench, filter geotextile wrap). It differentiates from sibling compute_french_drain by noting 'same enum as French drain' and mentions free-tier alternative compute_manhole, establishing unique 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?

Explicitly says 'Paid tier only' and describes the error response for unauthenticated calls (TIER_INSUFFICIENT). Points to signing up at a URL or using free-tier alternative compute_manhole. This provides clear when-to-use and when-not-to-use guidance with a direct 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 annotation readOnlyHint:true indicates no side effects. The description elaborates on behavior: auto-generates CrossSection series, delegates to end_area_earthworks engine, inherits rendering invariant, and computes topsoil strip footprint. It does not contradict annotations and adds useful behavioral context beyond what annotations provide.

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 paragraph of about 5 sentences, front-loading the critical paid-tier warning, then covering geometry, delegation, and additional features. Each sentence adds value, though a bulleted list could improve scannability. Still concise and well-structured.

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 nested parameters, output schema exists), the description covers core functionality, delegation, special features (topsoil strip, founding excavation), and rendering standards. It provides sufficient context for an AI agent to understand what the tool does and its key characteristics.

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

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

Schema description coverage is 50%, but many parameters have detailed descriptions in the schema. The description adds meaning by mentioning crest width, side slopes, height profile, topsoil strip, and founding excavation, which map to schema parameters. It enriches understanding of how these parameters are used without repeating schema details.

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 embankment cross-section BoQ, specifies geometry-driven, trapezoidal, per MMHW Series 600, and lists key parameters (crest width, side slopes, height profile). It distinguishes itself from siblings by mentioning the paid-tier requirement and the free alternative compute_end_area_earthworks, making purpose and differentiation clear.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives explicit usage conditions: paid-tier only, authentication needed, returns TIER_INSUFFICIENT otherwise, and recommends the free alternative compute_end_area_earthworks. This provides clear when-to-use and when-not-to-use guidance, along with a direct 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?

Annotations indicate readOnlyHint=true, and description is consistent. Beyond annotations, the description details the computation method (Simpson's Rule, trapezoidal fallback) and mentions rendering across standards. It adds context about free tier and anonymous access, which is helpful for understanding usage constraints.

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

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

Description is 3 sentences, front-loaded with 'Free tier. Anonymous callers welcome.' It packs substantial technical detail without being overly verbose. Could be slightly more structured, but it is efficient for the complexity involved.

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 inputs (nested objects, many parameters) and presence of an output schema, the description covers the main computation aspects: integration method, class tagging, mass-haul, cut/fill balance, routing, and rendering standards. It misses some specifics but provides sufficient context for an AI agent to understand the tool's scope.

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 descriptions are detailed for many parameters (e.g., bulking factor with typical values). The tool description adds overall context about the method and standard but does not significantly enhance individual parameter meaning beyond what the schema already provides. Schema coverage is high, so baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly states it computes end-area earthworks BoQ using Simpson's Rule with fallback, and specifies the standard (MMHW Series 600). The title 'Compute End-Area Earthworks BoQ' uses a specific verb and resource, and the description distinguishes it from sibling tools (e.g., compute_embankment_cross_section) by mentioning BoQ rendering and class tagging.

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?

Description mentions 'Free tier. Anonymous callers welcome.' which implies it's freely available but does not provide explicit when-to-use or when-not-to-use guidance compared to alternatives. The context of linear earthworks is clear, but no exclusions or alternative tool references are given.

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 the paid tier restriction and the TIER_INSUFFICIENT error, which is beyond what annotations provide. The readOnlyHint annotation is consistent with the tool's read-only computation nature. However, it does not mention other behavioral details like idempotency or 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 well-structured with a clear hierarchy and front-loads the paid tier warning. It is appropriately sized for the complexity, though slightly verbose in listing components.

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, output schema, standards), the description provides high-level context: components, standards, traffic categories, and access restrictions. It does not detail the output format, but an output schema exists to cover that.

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 value by summarizing the build-up components and indicating defaults for a typical road, but it does not provide detailed semantics for each parameter. With schema description coverage at 50%, the description partially compensates but not fully.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it computes a flexible (bituminous) pavement build-up BoQ, listing specific components and standards. It also distinguishes from the sibling tool compute_end_area_earthworks as a free-tier alternative, providing a specific verb and resource.

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 the paid tier requirement and provides a free-tier alternative (compute_end_area_earthworks). It also gives context on traffic categories and standards rendered. However, it does not explicitly state when to use this tool versus other pavement-related siblings 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?

Beyond the readOnlyHint annotation, the description discloses that the tool is paid-tier only and will return TIER_INSUFFICIENT without authentication. It also explains the internal composition (bedding primitive with additions) and supported standards, adding behavioral context.

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

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

The description is three sentences long, front-loading the critical tier restriction, then defining the tool's function concisely. 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 (many parameters, nested objects, and an output schema), the description covers the core function, tier restriction, alternative tool, and supported standards. It does not explain parameter interactions or output format, but the output schema presumably handles that.

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 high-level context for parameters (e.g., three additions: perforated carrier, filter geotextile wrap, optional top seal) which maps to parameters like has_top_seal and has_filter_wrap. However, it does not detail individual parameter meanings or syntax beyond what the schema (with some descriptions) already provides. Schema description coverage is low, but 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 the tool computes a Bill of Quantities for a French (filter) drain, using specific verb 'compute' and resource 'French (Filter) Drain BoQ'. It distinguishes from the sibling tool 'compute_manhole' 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 states the paid tier requirement and provides a free-tier alternative (compute_manhole). It also explains the context of use (perforated land drain in granular-filled trench with geotextile wrap) and the standards supported, helping the agent decide 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?

Beyond the readOnlyHint annotation, the description discloses the paid-tier requirement, the TIER_INSUFFICIENT error, and details about internal structure (discriminator pattern, WorkCategories, standards). This adds significant behavioral context.

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 verbose with many technical details that are not essential for selecting/invoking the tool. It could be significantly shortened while retaining key 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, the description covers the structural forms, presets, and standards comprehensively. The presence of an output schema reduces the need to explain return values, so the description 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?

The description provides context for the gabion_form discriminator and mentions sensible defaults, but does not systematically explain all parameters. With 50% schema coverage, the description adds some value but not enough to fully compensate.

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, and distinguishes it from the free-tier alternative compute_cantilever_wall. The purpose is specific, though the description buries the main verb somewhat.

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 this is a paid-tier tool and names the free-tier alternative compute_cantilever_wall, giving clear context on when to use it versus 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?

Discloses paid tier and authentication behavior (returns TIER_INSUFFICIENT), default reinforcement zero, and lists computed items (excavation, drainage, etc.). No contradiction with annotations. Could mention idempotency or side effects, 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 informative but somewhat verbose, with detailed standards codes and pattern discussion. It front-loads the critical paid tier info, but the length could be reduced without loss of essential meaning.

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 object, output schema), the description is comprehensive: covers variants, standards, alternatives, authentication, and computed outputs. Leaves little ambiguity for an AI 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?

Adds meaningful context to parameters beyond the schema, e.g., explaining the 'wall_type' discrimination, the nominal_face_reinforcement parameter, and the eight variant presets. Schema description coverage is 50%, and the description compensates by explaining parameter combinations.

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 mass concrete gravity retaining wall, specifying concrete grades and cross-section. It distinguishes from the sibling tool 'compute_cantilever_wall' by mentioning 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?

Explicitly states paid tier requirement, provides alternative free tool, lists eight variant presets, and describes typical use cases (e.g., highway boundary wall). Also gives conditions for when to use (gravity walls) and when not (use cantilever if not authenticated).

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 does not contradict this. It adds behavioral details: 'Free tier. Anonymous callers welcome.' and internal logic like 'connection drain re-uses the bedding primitive,' providing useful 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?

At five sentences, the description is relatively concise. However, the first two sentences ('Free tier...') are tangential to purpose and could be moved or integrated. The technical details are front-loaded but could be more focused.

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 object, output schema), the description is incomplete. It does not explain the output format or how parameters affect the computation. The mention of 'four-standard rendering' is vague without defining the output structure.

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

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

Schema description coverage is 0% for top-level parameters. The description mentions only a few sub-parameters implicitly (kerb outlet, connection drain) but does not explain the majority (e.g., pot_depth_m, grating_type, connection_material). An agent must rely entirely on the schema, which also lacks descriptions for many fields.

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 'composite drainage inlet' consisting of specific components (gully pot, grating, kerb outlet, connection drain). The name and title reflect this, distinguishing it from sibling compute tools for other drainage structures like catchpits or manholes.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

No explicit guidance on when to use this tool versus alternatives. The description mentions 'highway/curtilage' in the title but does not provide scenarios or exclusions. With many sibling tools, an agent lacks context for 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?

Annotations already indicate readOnlyHint=true, and the description adds critical behavioral context: paid tier requirement, error handling (TIER_INSUFFICIENT), output format (dual-quantity WorkItem with length_m and volume_m3), and special handling for SMM7 (zero-priceable annotated line). 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 front-loaded with critical info (paid tier, purpose) and organized into clear sections. However, it includes some extraneous details (closure of leaf, sibling assembly numbers) that could be omitted for conciseness. Still, every sentence adds value to an agent selecting or invoking the tool.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the complexity of the tool (multiple standards, dual quantities, eight presets, paid tier) and the presence of an output schema, the description covers all necessary aspects: purpose, usage restrictions, parameter details, output behavior, and sibling context. It is comprehensive and leaves no major gaps 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?

The description provides extensive semantics beyond the schema, including a detailed 'Geometry interpretation' section explaining each parameter's role (e.g., length_m as chainage extent, trench_width_m for volume computation). The volume formula is given, and the hard_material_type enum is explained with standard mappings. This compensates for low schema 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 uses specific verb ('linear extra-over measurement') and identifies the resource ('hard material encountered during drainage trench excavation'). It clearly distinguishes between two types of hard material and references multiple standards, making the tool's purpose unmistakable among many similar computational tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly states that the tool is paid tier only and provides a free-tier alternative (compute_manhole). It also mentions the context of closing a leaf and lists sibling assemblies, giving the agent clear context for when this tool should be used versus 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 provide readOnlyHint=true, and the description adds that it is a free tier with anonymous callers welcome, which is a behavioral disclosure beyond annotations. It does not contradict annotations and provides additional context about accessibility.

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 at three sentences, front-loading the free and anonymous nature. It efficiently describes the headwall components and standards 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 (30+ parameters, multiple siblings, output schema exists), the description only covers the tool's purpose and high-level features. It lacks details on parameter usage, return values, or how to properly configure inputs, making it incomplete for effective use.

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% (only one property has a description). The description does not explain any parameters beyond vague mentions of construction method and standards. It fails to compensate for the lack of schema descriptions, leaving the agent without guidance on the many dimensions, reinforcements, and other 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 title and description clearly state the tool computes a BoQ for a reinforced concrete outfall headwall. The description specifies the structure (back wall, wing walls, apron, scour protection) and construction types (in-situ or precast), distinguishing it from siblings like compute_headwall_precast and compute_headwall_attenuation_outlet.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage for outfall headwall BoQ calculation and mentions four standards (CESMM4, NRM2, MMHW, SMM7), but does not explicitly state when to use this tool over alternatives or when not to use it. No direct comparison with 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 adds behavioral context beyond the `readOnlyHint` annotation by disclosing the paid tier requirement and the TIER_INSUFFICIENT response. It also explains the composition pattern and commercial significance, which are not captured by annotations. 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 dense and includes technical jargon (e.g., 'bundle-with-shared-envelope pattern') that may reduce clarity for some users. It front-loads critical information (paid tier, alternative) but could be more concise to improve readability.

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 multiple components and parameters, the description provides a good overview of what it does, its commercial implications, and how it relates to siblings. It omits details about the output schema, but since an output schema exists, this is acceptable. Slightly more detail on usage patterns 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?

The input schema already provides detailed descriptions for many parameters (e.g., size, bedding_type, scour_protection_type). The tool description adds high-level context but does not directly elaborate on each parameter. Schema description coverage is 50%, so the description complements adequately but does not significantly enhance parameter understanding 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 identifies the tool's purpose: computing a BoQ for a controlled attenuation outlet headwall with precast concrete headwall, outlet-control ironmongery, and scour protection. It distinguishes from the free-tier sibling `compute_headwall` and specifies the paid tier requirement.

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 'Paid tier only' and directs users to the free-tier alternative `compute_headwall` for cases without authentication or budget. It also explains when to use this tool over others based on commercial and pattern 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 provide 'readOnlyHint: true', and the description adds context about authentication requirements, tier-based access, and the error message returned otherwise. It does not contradict 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 (3 sentences) and front-loaded with the critical paid-tier warning. All sentences add value, though it could be slightly restructured 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 high parameter count and existence of an output schema, the description covers the essential purpose, scope, and alternatives. It lacks detailed parameter guidance but is sufficient for understanding the tool's role.

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

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

Schema description coverage is 50%, and the tool description provides general context (excavation, bedding, scour protection) but does not individually explain all parameters. Some parameters lacking schema descriptions are not addressed 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 title 'Compute Precast Concrete Outfall Headwall BoQ' and description clearly state the tool's purpose: computing a Bill of Quantities for precast concrete outfall headwalls. It specifies the resource (precast headwall), verb (compute), and distinguishes from the free-tier sibling 'compute_headwall'.

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 'Paid tier only' and directs users to the free-tier alternative 'compute_headwall' for non-authenticated access. It clearly indicates when to use this tool (paid, authenticated account) and when not to.

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 significant behavioral context beyond the readOnlyHint annotation, including the tier restriction and detailed computation logic (e.g., 20-cell grid via 5 channel types × 4 depth classes). 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 verbose and includes highly specific internal details (e.g., 'FOURTH 2D-banded handler', 'code 500.8.{t}.{d}'), which may hinder quick scanning. It is structured but lacks brevity for a tool description.

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) and the presence of an output schema, the description provides substantial context about standards, classification, and processing logic. It adequately supports agent usage.

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 descriptions for parameters are already comprehensive, covering enums and defaults. The tool description does not add further parameter semantics beyond what the schema provides. Baseline of 3 applies as schema coverage is effectively 100%.

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 Highway Drainage Channel BoQ, referencing specific standards (BS EN 1433, SHW, HD 33/16) and listing channel classifications. It distinguishes from siblings by mentioning 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?

The description explicitly notes it is paid tier only and provides a free alternative, effectively guiding when to use. However, it does not elaborate on alternative tools for related drainage tasks within the same tier.

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 adds behavioral context: paid tier requirement, output items (excavation, sub-base, concrete, etc.), and supported standards. 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 thorough and front-loaded with the critical tier restriction. Every sentence adds value, though it could be slightly more concise given the 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, the description covers all essential aspects: purpose, outputs, standards, and tier restriction. Since an output schema exists, return values are not expected in the 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 50%. The description provides overall context for the parameters but does not add detailed per-parameter semantics beyond what's in the schema. Adequate but not compensatory.

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 linear precast concrete kerb run, specifying materials and standards. It differentiates from the sibling tool compute_cantilever_wall by noting the paid-tier restriction.

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_cantilever_wall). Does not elaborate on other when-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?

Annotations declare readOnlyHint=true, which is consistent with a compute operation. The description adds no contradictions. It discloses the paid tier requirement and authentication, but does not elaborate further on side effects or state changes beyond the read-only nature.

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 with three sentences containing many technical details. It is front-loaded with the paid tier info, but the detailed classification grid discussion could be streamlined. It is adequately concise for the 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 the tool's complexity (24-cell grid, multiple enums) and the presence of an output schema, the description covers authentication, purpose, discrimination logic, and standard references. It does not describe return values, but the output schema fills that gap.

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 explains how enums like column_type, foundation_type, luminaire_type, and bracket_type are used as discriminators in the computation, adding meaning beyond the schema descriptions. Schema coverage is ~50%, but the description compensates by explaining the role of parameters in the banding grid.

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 specifies 'Highway / street lighting column installation per BS EN 40 + BS 5489-1:2020 + TR 22', clearly stating it computes BoQ for lighting columns. It distinguishes from siblings by mentioning the free-tier alternative compute_end_area_earthworks, but does not explicitly differentiate among other compute_* tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly states 'Paid tier only' and provides an alternative: 'use the free-tier alternative compute_end_area_earthworks'. It also warns of the TIER_INSUFFICIENT error without authentication. This gives 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?

Annotations declare readOnlyHint=true, and the description adds that it is free tier and accepts anonymous callers, which is valuable 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?

Two sentences, front-loaded with important free/anonymous info, but the second sentence is a long list that could be more structured.

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?

Output schema exists, and the description states it computes BoQ, but for a tool with many parameters, it lacks detailed input instructions.

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%, and the description does not explain individual parameters despite listing the composite assembly components.

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 circular manhole and lists components, but does not explicitly distinguish from the sibling compute_manhole_precast, which could be confusing.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool versus alternatives, such as compute_manhole_precast or other compute 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 declare readOnlyHint=true, and description does not contradict. Description adds context about paid tier error (TIER_INSUFFICIENT) and the full scope of manhole components and standards, providing 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?

Description is dense and informative but lengthy (several sentences). Front-loads the paid tier info, but overall structure is a single paragraph. Could be more concise with bullet points.

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 complex tool with many parameters and existing output schema, description covers purpose, constraints, standards, and alternatives. Lacks example usage but is reasonably 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?

With 50% schema description coverage, the description adds context about catalogue-driven sizing and overriding fields, but does not explain individual parameters beyond size range. Adequate but could do more to highlight key 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?

Clearly states 'Compute Precast Concrete Monolithic Manhole BoQ' and describes the specific type of manhole. Distinguishes from sibling compute_manhole by noting paid tier and 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?

Explicitly mentions paid tier requirement and provides free alternative compute_manhole. Implicitly indicates usage for monolithic precast manhole calculations. Does not explicitly exclude other manhole types 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?

The description reveals beyond annotations that the tool requires a paid account and returns a specific error if not authenticated. Annotations already indicate readOnlyHint (non-destructive), and the description adds paid-tier context, which is valuable behavioral information.

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

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

The description is three sentences, tightly packed with critical information first (paid tier, error, alternative), followed by the foundation type and technical details. 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?

The description sets high-level context (paid tier, foundation type, standards) but lacks parameter guidance and does not explain what the BoQ output contains. An output schema exists, which partially compensates, but for a complex tool with many parameters, more detail 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?

With 0% schema description coverage and 19 parameters in the nested params object, the description provides no per-parameter meaning. It only mentions 'optional pedestal' but does not explain any of the defaulted parameters or how they influence the computation.

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 concrete pad foundation, distinguishing it from the free-tier alternative compute_cantilever_wall. It also mentions specific standards (BS 8666:2020) and features like optional pedestal, making the purpose explicit.

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 'Paid tier only' and provides a clear alternative (compute_cantilever_wall) for free use. It also warns about the TIER_INSUFFICIENT error for unauthenticated calls. However, it does not cover other usage conditions like parameter constraints or when not 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 declare readOnlyHint=true, implying no side effects, but the description details 'opens highway_bridge_edge L2 leaf,' 'closing the highway suite,' and 'launch target,' suggesting state-modifying actions. This is a direct 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 overly verbose with many technical details and internal platform references (e.g., 'MMHW Series 400 _parapet handler,' 'LAUNCH-COMPLETING 45TH ASSEMBLY'). It front-loads important info but then descends into confusing jargon, reducing 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?

Despite complexity (multiple enums, standards, and an output schema likely present), the description focuses on internal mechanics rather than explaining what the tool outputs (e.g., BoQ quantities) or how parameters affect results. Missing context on return values and practical usage.

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 50%, and the description adds context for parapet_type and containment_level with standard references. However, much of the description is extraneous internal jargon (e.g., 'SEVENTH 1D-banded handler') that does not aid parameter understanding, limiting added 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 the tool computes a Bill of Quantities for bridge/structural deck parapet installation per multiple UK standards (BS 6779-1, BS EN 1317-2, SHW Cl. 408). It specifies the parapet system classifications and discriminators, making its purpose distinct 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?

The description explicitly notes it is paid-tier only and names a free-tier alternative (compute_end_area_earthworks). It provides authentication requirements and references standards, but lacks comprehensive guidance on when to prefer this over all 44 sibling compute 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 already indicate readOnlyHint=true, but description adds critical behavioral traits: requires paid account, details output components (excavation, tanking liner, etc.) and routing logic via discriminators. 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?

Description is dense but well-structured, front-loading the paid tier warning. Every sentence adds value, though overall length could be reduced. Technical details are necessary for this complex tool.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (many parameters, nested object, output schema exists), the description covers standards, output components, and routing logic. It is sufficiently complete for an agent to use, though some parameter details rely on 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?

Schema coverage is 50% and schema includes descriptions for many parameters (surface_type, infiltration_system, etc.). Description adds context on UK standards and mapping to PavementFamily enum, but does not significantly enhance understanding beyond schema. Baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it computes permeable pavement BoQ per CIRIA C753, specifies the three UK surface types and infiltration regimes, and distinguishes it from siblings like compute_flexible_pavement and 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 states it is paid tier only, warns of TIER_INSUFFICIENT error without authentication, and provides a free-tier alternative (compute_end_area_earthworks). Also implies usage context for UK civil engineering projects.

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?

While annotations declare readOnlyHint=true, the description adds valuable behavioral context: it requires authentication, returns TIER_INSUFFICIENT on failure, and opens the drainage_treatment leaf. It does not contradict annotations and supplements them with concrete 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 the critical paid-tier warning, but it is lengthy and includes many engineering specifics (e.g., code references) that, while informative, reduce conciseness. It is organized but 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 tool's complexity, the presence of an output schema (which doesn't need explanation), and the detailed parameter descriptions in the schema, the tool description covers the essential aspects for correct selection and invocation, though it could explicitly state the output format.

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 50% schema description coverage, the description adds meaning for key parameters (size, class, type) by explaining their roles and values, but many sub-parameters (dimensions, quantity) lack elaboration. The description partially compensates but not fully.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The title and description explicitly state the tool computes a Bill of Quantities for a prefabricated petrol/oil interceptor, specifying the resource (BoQ) and action (compute). It distinguishes from sibling tools like compute_manhole by noting it's a 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?

The description clearly states the tool is paid-tier only and provides an alternative (compute_manhole) for free-tier users. It also explains when to use it (e.g., for hot-spot catchments) and routes via multiple standards, giving explicit context for 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?

Annotations only provide readOnlyHint: true. The description adds the tier restriction and error response, which is beyond annotations. It also describes the design pattern (strategy) and standards used, aiding understanding. No behavioral contradictions.

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 but well-structured, front-loading the tier restriction. Every sentence provides distinct value: tier info, alternative, design pattern, standards, and outputs. Slightly long but 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 the complex nested schema and presence of output schema, the description covers overall strategy, standards, and emission items. It lacks detailed parameter explanations but provides enough context for tool selection. With output schema available, return values are documented elsewhere.

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

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

Schema description coverage is 0%, so the description should compensate. It explains the key parameters like bedding_class and bedding_context at a high level (highway vs building, class list) but does not detail other parameters like pipe_length or invert_depth. The schema has good enum descriptions, so the description adds some but not full 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 pipe bedding and surround BoQ, specifies the domain (highway vs building with standard references), and lists emitted items. It explicitly distinguishes from sibling tool compute_manhole by noting the 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 requirement and error behavior ('TIER_INSUFFICIENT'), provides sign-up link, and names the free-tier alternative compute_manhole. This gives 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 paid tier authentication requirement and TIER_INSUFFICIENT error beyond the readOnlyHint annotation. Explains the maturity pattern introduced, adding valuable behavioral context.

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?

Concise relative to information density; front-loaded with critical usage constraint. Each sentence adds value, though length is 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?

Covers purpose, constraints, standards, maturity pattern, sibling relation, and presets. Complete for a complex tool with output schema present.

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?

Description adds context about variant presets and test_method as discriminator, but schema already provides detailed descriptions for test_method. Schema coverage is 50%, so description could compensate more but only marginally adds 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?

Clearly states it provides linear measurement of testing on new drainage pipework, listing specific test methods and standards. Distinguishes from siblings by being part of 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?

Specifies paid tier requirement and suggests free-tier alternative compute_manhole. Provides context for when to use this tool, though not explicit exclusions for all 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?

Annotations declare readOnlyHint=true, and the description adds behavioral context about returning TIER_INSUFFICIENT without authentication, which is valuable. No contradiction noted.

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

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

The description is front-loaded with the most critical info (paid tier, free alternative) but becomes excessively detailed with references to work codes and variant presets, reducing 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?

For a complex tool with many parameters and siblings, the description covers purpose, authentication, alternative, and facing options. Output schema exists, so return values need not be detailed, but error handling beyond authentication 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?

The description provides detailed explanations of the four facing systems and typical uses, adding meaning beyond the schema's descriptions. While many sub-parameters have schema descriptions, the tool-level description contextualizes parameter choices effectively.

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 it computes an RSW BoQ, names the paid tier requirement, and distinguishes from the free sibling tool compute_cantilever_wall. This gives a clear verb+resource with differentiation.

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 when to use (paid tier) and provides an explicit free alternative (compute_cantilever_wall). However, it does not guide on choosing among other wall compute tools like compute_gabion_wall or compute_gravity_wall, leaving some gap.

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?

While annotations indicate readOnlyHint, the description adds important behavioral context: it requires authentication, returns TIER_INSUFFICIENT for unpaid accounts, and details the computational 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 detailed and well-structured, front-loading critical info (paid tier) and organizing components and routing. It is slightly long but every sentence adds value; minimal 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 complexity of the tool (rigid pavement with multiple layers, standards, and reinforcement), the description is comprehensive. It covers paid restriction, components, defaults, routing, and even cites specific standards (DMRB CD 226, BS 8666:2020). The presence of an output schema further reduces need for return value explanation.

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 explains defaults (e.g., 50m x 7m urban distributor, JRC with 25m bay) and context for parameters beyond the schema. The schema itself has detailed descriptions (e.g., pavement_type enum meanings), but the description adds real-world usage context.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it computes a rigid pavement build-up BoQ, specifying components like capping, sub-base, membrane, and slab variants. It distinguishes itself from siblings like compute_flexible_pavement and compute_end_area_earthworks, making its purpose unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly mentions paid tier requirement and provides an alternative free-tier tool (compute_end_area_earthworks). It also implies use for rigid pavement, not other pavement types, 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 and tier insufficiency, and references read-only behavior via the 'readOnlyHint' annotation. The annotation confirms it's a read operation, and the description adds context about authentication and tier restrictions, which are helpful.

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 internal implementation details (e.g., 'THIRD member of the highway L1 leaf', '26th use of classed-then-legacy') that are not helpful for an agent. It could be more concise and front-loaded with agent-relevant 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, enums, discriminators, and UK standards references), the description covers the purpose, usage constraints, parameter semantics, and presets thoroughly. The output schema exists, so return values need not be explained.

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 significant meaning beyond the schema by explaining geometry interpretation (line_length_m vs area_m2), discrimination/banding logic, and defaults anchored to a specific scenario. Given 50% schema coverage, the description compensates well, providing essential usage context for 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 road marking Bill of Quantities, specifies it is paid tier, and distinguishes from sibling 'compute_end_area_earthworks' as a free alternative. It details the classifications (marking_line_type, area_marking_type, symbol_type, stud_type) making it easy to understand its function.

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 the tool is paid tier and suggests the free alternative 'compute_end_area_earthworks'. It also notes authentication requirements, but does not explicitly state when to use this tool over other siblings beyond the paid/free distinction.

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 annotation readOnlyHint=true indicates no side effects. The description adds context about wrapping the combined engine and re-tagging emissions. It does not contradict 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 efficiently packs essential info (pricing, alternatives, internal mechanics, standards) without redundancy. Front-loaded with the most critical detail.

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, standards, internal wrapping) and the presence of an output schema, the description covers the core functionality and integrates well with the 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?

Schema description coverage is 50%, but the description adds value by explaining that defaults align with NJUG 7 and that the function builds internal objects. Some sub-parameters have schema descriptions, but the overall description 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 'Single-service utility run per NJUG Volume 1' and lists the specific services (water, gas, etc.). It distinguishes from siblings like compute_combined_services_trench by noting it wraps the combined engine for a single band.

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 directs users to the free-tier alternative compute_manhole. This provides 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?

Despite readOnlyHint annotation, description adds substantial behavioral context: authentication needed, wraps attenuation_tank, emits specific items, and imposes constraints on hot-spot categories. 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?

Front-loaded with critical access info. While thorough, the description is somewhat lengthy; however every sentence provides value and maintains 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?

Covers authentication, usage constraints, parameter semantics, behavioral notes, and references to standard and output. Fully equips agent to decide and invoke correctly despite complexity.

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

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

Adds meaning beyond input schema by explaining two design storm specification methods, soil characterization parameters (infiltration rate, confidence, hot-spot), and geometry usage. Complements the detailed 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?

Clearly states it computes a CIRIA C753 infiltration soakaway and BoQ. Differentiates from sibling compute_attenuation_tank by specifying it is a paid-tier alternative. Specific verb and resource.

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, authentication behavior, and refers to free-tier alternative compute_attenuation_tank. Also notes the engine refuses VERY_HIGH hot-spot catchments per C753 restrictions.

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 readOnlyHint=true. The description adds value by disclosing the authentication requirement and the TIER_INSUFFICIENT error, which is 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 very long and dense with detailed code references and enumeration of patterns. While front-loaded with critical info, it could be trimmed for readability 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 (many parameters, four face systems, multiple standards), the description is remarkably comprehensive. It covers geometry, face system choices, and coding standards, leaving little ambiguity for an agent to 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?

Despite 50% schema description coverage, the description provides extensive context for parameters, including geometry interpretation, face-system-specific attributes, and instructions on how to handle variable-length schemes. This greatly enhances 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 the tool computes a Bill of Quantities for soil-nailed slopes. It distinguishes itself from siblings by mentioning its place in the earth_structures hierarchy and comparing to the free-tier alternative 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 this tool is for paid users only and provides the free alternative. It details when to use each face system for different scenarios, giving clear guidance on 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?

Annotations already provide readOnlyHint=true. Description adds authentication requirement, error behavior, standards integration, and stepping feature. No contradictions; adds valuable 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?

Every sentence adds value: paid tier warning, alternative, functionality, launch context, standards, and stepping demo. Front-loaded with critical info. No wasted words.

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 purpose, usage constraints, standards, and integration. Output schema exists so return values are not needed. Missing guidance on the 'standard' parameter, but overall sufficient given complexity.

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

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

Schema description covers the params object with detailed defaults explanation (baseline 3). Description does not add further parameter details beyond the schema, nor does it explain the 'standard' enum. Adequate but not exceptional.

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 linear reinforced concrete strip foundations, level or stepped. It distinguishes itself from siblings by naming the free-tier alternative compute_cantilever_wall and positioning itself alongside pad_foundation in the P1 launch set.

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, returns TIER_INSUFFICIENT if not authenticated, and provides free-tier alternative. Mentions integration with BS 8666:2020. However, it lacks explicit guidance on when to use this vs other foundation tools like pad_foundation.

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, consistent with a computation tool. Description adds authentication requirements and error handling context. No contradictions, but lacks details on output or side effects beyond the tier check.

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 informative and well-structured, but slightly verbose. Key information is front-loaded (paid tier, alternative) and technical details follow. Could be trimmed slightly without losing value.

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 (19 parameters, nested objects) and presence of output schema, the description provides a solid overview of the tool's domain and design palette. Lacks detailed parameter explanations but sufficient for an experienced 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?

Schema description coverage is 0% - no parameter descriptions in schema. The description adds high-level context (lining strategies, optional check-dams) but does not explain each parameter individually. Baseline 3 is appropriate given moderate 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 a SuDS swale BoQ per CIRIA C753, with specific channel types and strategies. It distinguishes itself from sibling tools by naming the free-tier alternative 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 declares paid-tier requirement and auth failure behavior (TIER_INSUFFICIENT). Provides a direct alternative (compute_attenuation_tank) for free tier users. Mentions cross-standard compatibility.

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, implying no state mutation. The description adds value by disclosing the authentication behavior (returns TIER_INSUFFICIENT without account) and the paid tier requirement. It also lists classification standards but does not explicitly confirm read-only nature. The added context about error handling justifies a 4.

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 verbose, including irrelevant internal metadata such as '25th use of classed-then-legacy attribute discrimination pattern' and '41st assembly'. This padding detracts from conciseness and readability. The key information could be conveyed in half the length, making it harder for an agent to parse efficiently.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (many parameters, multiple classification standards, output schema exists), the description covers essential contextual information like TSRGD classifications and work category entries. With the output schema handling return structure, the description does not need to explain output format. It is sufficiently complete for an agent to invoke the tool correctly.

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

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

The input schema already has detailed descriptions for most parameters (e.g., sign_type, face_area_class), giving high schema coverage. The tool description adds strategic context, such as the five commercial presets ('rural warning triangle on single post') and the standards codes (CESMM4, NRM2, MMHW). This extra layer helps the agent understand real-world usage beyond the schema, warranting a 4.

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 traffic sign installation per specific standards (SHW, TSRGD). It identifies the verb 'compute' and the resource 'Traffic Sign BoQ'. It also differentiates from the free-tier sibling tool compute_end_area_earthworks. However, the description is cluttered with internal assembly hierarchy details (e.g., 'SECOND member of the highway L1 leaf') that do not directly aid purpose clarity, so it falls short of a perfect 5.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly states 'Paid tier only' and warns of a TIER_INSUFFICIENT error if not authenticated. It provides an immediate alternative: 'use the free-tier alternative compute_end_area_earthworks'. This gives clear when-to-use and when-not-to-use guidance, which is excellent for an AI agent.

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 catalogue-driven behavior and defaulting mechanisms for chamber type and supply route. Annotations indicate readOnlyHint=true, which is consistent with a computation tool. No contradictions.

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 (over 150 words) with dense technical details. While informative, it could be more concise; the front-loading of payment info is good, but the latter part may overwhelm 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 (catalogue, multiple standards, many parameter defaults), the description provides a comprehensive overview. References to CESMM4, NRM2, etc., and an output schema likely fill remaining gaps.

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

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

With 50% schema coverage, the description adds significant semantic value: explains catalogue defaults, supply route overrides, and how parameters resolve. It more than compensates 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 Bill of Quantities for a utility access chamber, covering ten standard UK types. It distinguishes itself from the sibling compute_manhole by specifying it's a 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 states 'Paid tier only' and provides a free-tier alternative (compute_manhole). Also mentions authentication requirement and points to a sign-up link for access.

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 adds important behavioral context: it requires authentication, returns a TIER_INSUFFICIENT error if unauthorized, delegates to pad_foundation for substructure, and has catalogue-driven defaults for supply routes. This helps the agent understand side effects and constraints.

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

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

The description is a single dense paragraph containing all critical information (pricing, types, delegation, defaults). It is front-loaded with the most important detail (paid tier) but could benefit from bullet points or sub-sections for readability. Every sentence adds value, but overall density makes it less scannable.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (19 parameters, nested schema, output schema exists), the description covers the essential aspects: what it computes, the kiosk types, supply route logic, relation to pad_foundation, and access requirements. The output schema is already defined, so return values need not be explained. The description is sufficient for an agent to select and use 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?

The description adds meaning to the kiosk_type and supply_route parameters by explaining typical defaults (e.g., LV pillars are normally utility-provider-supplied). However, many other parameters (top_mat, cover_mm, etc.) are not elaborated, and the schema itself has minimal descriptions (only kiosk_type has a description). The domain context helps but doesn't fully compensate.

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 utility kiosk bases, listing specific types (LV pillar, FTTC cabinet, etc.) and distinguishing it from siblings like compute_manhole (free-tier alternative) and compute_pad_foundation (which it delegates to). The verb 'compute' combined with the resource 'Utility Kiosk Base BoQ' is specific and actionable.

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 this is a paid-tier tool, requires authentication, and points to a free alternative (compute_manhole). It also explains the typical usage context (utility cabinets). While it doesn't exhaustively list when not to use, the guidance is clear and practical.

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, consistent with computing a BoQ. The description adds valuable behavioral context, such as the tool being part of a larger assembly system and pattern usage, without contradicting 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 long but well-structured with clear sections and bullet points. Front-loads the important paid tier warning and purpose. Every sentence adds value, though could be 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 (many parameters, 50% schema coverage, existing output schema), the description is highly complete. Explains purpose, usage, parameter details, coding references, and even notes the tool's novelty in patterns.

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 50%, but the description extensively explains enum parameters (vrs_system_type, foundation_type, etc.) and geometry interpretation. Adds meaning beyond the schema for critical parameters, compensating for the coverage gap.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool computes a Bill of Quantities for vehicle restraint systems per SHW Cl. 401-419 and BS EN 1317. It distinguishes itself from siblings by noting it is the first member of the highway_restraint leaf and mentions 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?

Explicitly states 'Paid tier only' and provides instructions on authentication failure. Recommends the free-tier alternative compute_end_area_earthworks. Provides detailed guidance on when to use each vrs_system_type, containment level, and working width class.

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?

Adds value beyond readOnlyHint annotation by disclosing the paid-tier constraint and the TIER_INSUFFICIENT error envelope. No contradictions.

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

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

Two concise sentences, front-loaded with the core action. Every sentence provides essential information 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?

Suitable for a simple retrieval tool with an output schema. Covers purpose, auth requirement, and existence condition. No missing critical details.

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

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

With 0% schema description coverage, the description only adds 'by id', which is minimal. Does not elaborate on project_id format or where to obtain it.

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 fetches a project by ID, using a specific verb and resource. It distinguishes from sibling compute_* and save_project tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Mentions paid-tier restriction, providing clear context on who can use it. Does not explicitly exclude alternatives, but the purpose is unambiguous.

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

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

The description states 'Re-run every enabled assembly' implying a mutation, while annotations have readOnlyHint=true. This is a direct contradiction, severely undermining trust.

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

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

Two sentences, no fluff, but the paid-tier warning could be more integrated. 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?

Despite having an output schema, the description misses explaining the standard_codes parameter and contradicts annotations, leaving the agent confused about side effects.

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 should explain parameters. It mentions measurement standards but does not connect to 'standard_codes'. The schema's own description (not part of tool description) covers it, but the tool description adds no 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 the tool re-runs all enabled assemblies and renders aggregated BoQs for requested measurement standards, distinguishing it from sibling tools that compute individual 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?

It mentions paid tier restriction and anonymous caller error, providing clear context. However, it lacks explicit guidance on when not to use this vs. individual compute tools, though sibling names imply differentiation.

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 behavioral traits beyond annotations: Excel free with watermark/protection, Word paid and returns TIER_INSUFFICIENT for anonymous. The readOnlyHint annotation is consistent; description adds actionable constraints.

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

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

The description is a single paragraph but efficiently conveys purpose, usage rules, and wire shape. Every sentence is informative 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?

For a complex tool with nested schema and output schema, the description covers the core behavior and tier restrictions. It does not detail output format, but the presence of an output schema mitigates 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 description coverage is 100%, so baseline is 3. The tool description does not add meaning beyond the schema; it mentions skill options but does not elaborate on details already present in the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'Render previously-computed BoQ results into a deliverable (Excel workbook or Word report),' with specific details on free vs. paid versions. It distinguishes from sibling tools (all compute_* or project management) and provides context on wire shape.

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 explains when to use each skill (Excel free, Word paid) and the consequences for anonymous callers. It lacks explicit 'when not to use' but the context from siblings and the 'previously-computed' phrasing implies prerequisites.

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 the paid tier restriction and the resulting error envelope, which annotations (readOnlyHint=false, destructiveHint=false) do not cover. However, it does not disclose side effects like overwriting behavior or idempotency. Annotations already indicate mutation, so the 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?

Two sentences: one for purpose, one for usage restriction. No redundant words, front-loaded with key action.

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 core functionality and a key restriction, but lacks details on whether the tool creates or updates, or what is returned on success. Given the nested input schema, the description is somewhat terse and could better explain the save operation's behavior.

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

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

Schema description coverage is 100%, so baseline is 3. The description does not add any parameter-level details beyond the schema. The nested request object's properties 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 the tool persists a CivilQuants project with its assembly list, distinguishing it from sibling compute/get/recompute tools. The verb 'persist' and resource 'project' are specific, and the paid tier note adds clarity.

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 only mentions a paid tier restriction but provides no explicit guidance on when to use this tool versus alternatives like get_project or recompute_project. There is no when-not or context for selecting this tool.

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