civilquants

Compute Hard Material in Trench (extra-over) BoQ

compute_hard_material_in_trench

Read-only

Paid tier only. Calling this without an authenticated CivilQuants account returns TIER_INSUFFICIENT — sign up at https://civilquants.com/pricing or use the free-tier alternative compute_manhole. Linear extra-over measurement of hard material encountered during drainage trench excavation. Discriminates between natural rock (CESMM4 E.6 / NRM2 5.6.1 / MMHW 500.6.1 / SMM7 R12.6.1) and artificial hard material — buried concrete / masonry / obstructions (CESMM4 E.7 / NRM2 5.6.2 / MMHW 500.6.2 / SMM7 R12.6.2). The platform's first dual-quantity WorkItem: carries both length_m and volume_m3 so CESMM4/NRM2 (m³) and MMHW/SMM7 (m) each render with their correct unit per the standards' rules. Eight variant presets cover both hard-material types × four depth bands. SMM7 R12 deems trench excavation (including hard material) included in the pipe-run rate — the SMM7 handler emits a zero-priceable annotated line for tender transparency (third use of the deemed-included extra-over annotation pattern). Closes the drainage_ancillaries L2 leaf at 4/4 members. Sibling assemblies: connection_to_existing (S32), ditch (S33), pipework_testing (S33). Example params: length_m=10 m (0.5–500), max_depth_m=1.5 m (0.3–10), trench_width_m=0.7 m (0.3–3). Example call: {"params": {"length_m": 10, "max_depth_m": 1.5, "trench_width_m": 0.7}, "standard": "MMHW"}. Omitted parameters use sensible engineering defaults. Pass deliverables=["xlsx","dxf","pdf"] (any subset) to also receive one-shot download URLs in the same call: Excel BoQ (both tiers, watermarked free) plus the dimensioned DXF (CAD) and PDF drawing sheets (paid tier).

Input Schema

TableJSON Schema

Name	Required	Description	Default
`params`	Yes	Parameters for a single hard-material extra-over scenario. Geometry interpretation: - `length_m` is the chainage extent of the hard-material zone (i.e. how many metres of pipe-run encounter hard material). This is the MMHW/SMM7 quantity directly. - `trench_width_m` is the trench plan width at the level of the hard material — used (with height_of_hard_material_m and length_m) to compute the volumetric quantity used by CESMM4/NRM2. - `height_of_hard_material_m` is the vertical extent of hard material within the trench section — the bottom of the trench wraps the pipe envelope, so the hard-material height is typically less than the full trench depth. This is the QS's judgment, informed by site investigation. - `max_depth_m` is the depth (from finished ground level) to the bottom of the hard-material zone — drives the depth banding in all four handlers. - `pipe_diameter_mm` is descriptive only — propagated to the WorkItem for cross-referencing the carrier pipe. Volume = length_m × trench_width_m × height_of_hard_material_m.
`standard`	No		MMHW
`output_mode`	No		full_json
`deliverables`	No

Output Schema

TableJSON Schema

Name	Required	Description	Default
`result`	Yes

TDQS

A5/5.0

Behavior5/5

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

Discloses paid tier enforcement, authentication requirement, and the dual-quantity behavior across four standards. Does not contradict annotations (readOnlyHint is appropriate for a computation tool).

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

Conciseness5/5

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

Front-loaded with tier info and alternative, then logically structured: behavior, standards, parameters, example. Every sentence adds value; no redundancy.

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

Completeness5/5

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

Covers tier, standards, parameter semantics, example call, deliverables, and sibling context. Thoroughly equips an agent to select and invoke the tool correctly.

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

Parameters5/5

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

Despite low schema coverage (25%), the description provides extensive parameter details: ranges, defaults, engineering rationale, geometry interpretation, and examples. Fully compensates for schema gaps.

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

Purpose5/5

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

The description clearly states it computes extra-over measurement of hard material in trench excavation, specifies the dual-quantity nature (length and volume), and distinguishes from the free-tier alternative compute_manhole.

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

Usage Guidelines5/5

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

Explicitly states paid tier requirement and provides free-tier alternative compute_manhole. Also notes SMM7's deemed-included behavior, guiding appropriate usage.

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

All civilquants tools Inspect

Try in Browser

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A3.9/5.0

Disambiguation4/5

Most tools have distinct purposes with detailed descriptions, but the large number of closely related structures (e.g., multiple wall types, drainage inlets) could cause some confusion. Descriptions are thorough, mitigating ambiguity.

Naming Consistency4/5

The majority of tools follow a consistent `compute_<noun>` pattern. However, several administrative tools use different verbs (get, list, save, etc.), introducing mild inconsistency.

Tool Count3/5

56 tools is high but defensible given the broad civil engineering domain. The set covers many specific structures and workflows, though some tools could be merged or scoped more tightly.

Completeness4/5

The tool set covers a wide range of common civil engineering tasks (walls, foundations, drainage, pavements, highways, utilities). Minor gaps exist (e.g., no explicit bridge or tunnel tool), but the core domain is well-covered.

Resources

Need Help?