civilquants

Compute Traffic Sign BoQ

compute_traffic_sign

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_end_area_earthworks. Traffic sign installation per SHW Cl. 1201-1206 and TSRGD 2016. Discriminates between five TSRGD sign classifications via the sign_type enum: warning triangular, regulatory circular, regulatory rectangular, directional rectangular, and information rectangular. SECOND member of the highway L1 leaf (after S36 VRS) and FIRST member of the highway_signs_markings L2 leaf — 41st assembly. Five variant presets cover the principal UK commercial scenarios: rural warning triangle on single post, urban regulatory circular, rural advance directional on twin posts, motorway gantry ADS, and urban information rectangle. Routes via three new WorkCategory entries (TRAFFIC_SIGN_POST, TRAFFIC_SIGN_FACE, SIGN_FOUNDATION). Codes: CESMM4 X.4 (Class X §4 — traffic signs), NRM2 34.8 (Site works — signs), MMHW 1300.1.{a}.{h} (Series 1300 — Road Lighting/Traffic Signs/Bollards, with 2D banding by face_area × mounting_height), SMM7 Q40.6 (Section Q40 — Fencing/site furniture). 25th use of classed-then-legacy attribute discrimination pattern; 6th use of declared-then-banded AND the SECOND 2D-banded handler (MMHW 1300.1.{a}.{h} bands by both axes simultaneously). Example params: post_length_m=3 m (1.5–12), post_count=1 Nr (1–4), faces=1 Nr (1–6). Example call: {"params": {"post_length_m": 3, "post_count": 1, "faces": 1}, "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 traffic sign installation. Geometry interpretation: - ``post_length_m`` is the length of the supporting post above ground (UK convention measures the above-ground length, not the often-greater driven/embedded length). For gantry signs, this is the height of each gantry leg. - ``post_count`` is the number of supporting posts. Typical values: 1 (small warning/regulatory), 2 (twin-post directional, gantry legs). - ``faces`` is the number of distinct sign faces on the assembly. A single gantry can carry 1-3 distinct sign faces (one per lane); a twin-post directional can carry advance and confirmation faces. Face geometry: - ``actual_face_area_m2`` is the m² of a single face (used for face-area descriptions; the WorkItem quantity is enumerated per face). Foundation: - ``foundation_type`` carries the SHW Cl. 1204 classification. - ``concrete_grade`` is for description text — concrete is deemed-included in the foundation unit rate (no separate CONCRETE line emitted). - ``approximate_foundation_volume_m3`` is for description text only — UK QS convention does not measure sign-foundation concrete separately (see SHW Cl. 1204).
`standard`	No		MMHW
`output_mode`	No		full_json
`deliverables`	No

Output Schema

TableJSON Schema

Name	Required	Description	Default
`result`	Yes

TDQS

A4.1/5.0

Behavior4/5

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

Discloses authentication requirements, tier insuffiency error, and deliverable URLs. Annotations already set readOnlyHint=true, so the description adds value by detailing the paid-tier restriction and error behavior without contradiction.

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

Conciseness2/5

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

The description is extremely verbose, listing numerous codes, standards, and leaf relationships. While informative, it lacks conciseness and could be better structured with bullet points or sections.

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

Completeness4/5

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

Covers authentication, standards, sign types, presets, codes, example calls, and deliverables. With a complex input schema and output schema, the description provides comprehensive context, though it could be more streamlined.

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

Parameters3/5

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

Schema description coverage is 25%, but the schema itself has extensive descriptions for each parameter. The tool description adds some additional context (e.g., leaf membership, codes) but not significant parameter-level details beyond what the schema provides.

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 the tool computes a traffic sign BoQ, distinguishing it from the free-tier alternative compute_end_area_earthworks. It also provides context on sign classifications and standards, making the purpose unmistakable.

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

Usage Guidelines5/5

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

Explicitly states 'Paid tier only' and directs users to the free alternative. Describes when to use different sign types and presets, and mentions deliverables options. Provides clear guidance for correct invocation.

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?