Skip to main content
Glama

civilquants

Compute Lighting Column BoQ

compute_lighting_column
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. Highway / street lighting column installation per BS EN 40 + BS 5489-1:2020 + TR 22. Discriminates between four UK column material classifications via the column_type enum (steel_galvanised, aluminium, composite_grp, decorative_cast_iron). Plus parallel discriminators on three further WorkCategory entries: foundation_type on COLUMN_FOUNDATION, luminaire_type on LUMINAIRE, bracket_type on COLUMN_BRACKET. The MMHW Series 1300 _lighting_column handler is the platform's THIRD 2D-banded handler — code 1300.4.1.{h}.{c} bands by column_height_class (6 bands per TR 22) AND column_loading_class (4 bands per BS EN 40-3). 6×4 = 24-cell grid (the LARGEST banded grid in the platform). Example params: mounting_height_m=6 m (4–16), luminaire_wattage_W=60 W (10–1000), bracket_count=0 Nr (0–4). Example call: {"params": {"mounting_height_m": 6, "luminaire_wattage_W": 60, "bracket_count": 0}, "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
NameRequiredDescriptionDefault
paramsYesInputs for the lighting_column assembly. Defaults anchored to URBAN_6M_LED — UK urban distributor: 6 m steel galvanised column on precast socket, BS EN 40-3 Class B, LED M-class luminaire (~60 W typical). Required-field defaults added per G.6.7.24 precedent — non-breaking API enrichment opens the slug to schema- driven workspace defaults.
standardNoMMHW
output_modeNofull_json
deliverablesNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

TDQS

A4.5/5.0
Behavior4/5

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

Discloses authentication requirement and tier restriction. Describes the large 24-cell banded grid and the return of download URLs for deliverables. Annotations already declare readOnlyHint=true, so no contradiction; the description adds useful context about the computation's scope.

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

Conciseness3/5

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

The description is comprehensive but quite verbose, with a lot of internal detail (e.g., banded grid, handler code). The first sentence captures purpose, but overall could be more concise to reduce processing overhead for an AI agent.

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?

Given the complexity of parameters, nested objects, and multiple standards, the description covers purpose, usage, parameter defaults, examples, and output formats. An output schema exists, so return values are handled externally.

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

Parameters4/5

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

Schema description coverage is 25%, but the description elaborates on key enums (column_type, foundation_type, etc.) and explains defaults. Adds meaning beyond the schema for the major parameters, though not exhaustive for all 11 sub-parameters.

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 BoQ for highway/street lighting column installation per BS EN 40 + BS 5489-1:2020 + TR 22. It names the output (Excel, DXF, PDF) and distinguishes from the free-tier sibling 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.

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 provides the free-tier alternative. Includes example parameter values and a full example call, plus explains default behavior and optional deliverables.

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

Try in Browser

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