Skip to main content
Glama

Craft Quantities: construction material calculators

Materials list for a whole job (takeoff)

run_takeoff
Read-onlyIdempotent

Works one whole-job takeoff, identified by its id, from the measurements given: the materials list of a job such as a slab or a deck, each line from its own calculator, with what to order, waste allowances, metric and US units, labour hours (not a price), what is not counted, a citation and the page link. It does not size structure.

Input Schema

NameRequiredDescriptionDefault
detailNofull (the default): the whole answer. summary: the result lines, the citation line and the page only — fewer tokens to read.full
marketNoOptional. A market whose own opening choice some inputs take (a UK reader's code, an IEC motor), and whose currency symbol prints the caller's own money figures.
systemNoThe unit system inputs left out open in, and the one the page link opens in. The answer comes in both.metric
takeoffYesA takeoff id, such as concrete-slab.
leaveOutNoRows the reader leaves out of the job: still worked and shown, not put in the project or counted in labour.
selectionNoBuild-up choice id → option id, the takeoff's own (a stud size, an insulation, a cladding). Choices left out take the page's own for the system.
allowancesNoRow → an allowance the reader sets: a percentage (cutting waste, overlap), or the option an allowance follows (a lay pattern). Row names are the takeoff's steps (the calculator slug, or the step key where one runs twice).
inputUnitsNoSend "base" to pass bare numbers on dimensioned inputs in base units (m, m², L, kg …), as the published test vectors are written. Without it a length, area or volume must carry its unit.
measurementsNoMeasurement id → value, each length, area or volume with its unit ("12 ft", {"value": 3.6, "unit": "m"}); counts as numbers. Ids are those of the takeoff; any left out opens at the page's own figure.

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A3.7/5.0
Behavior4/5

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

Annotations already declare a read-only, idempotent, non-destructive, closed-world call, so the safety profile is covered. The description adds real behavioral context beyond them: labour hours are reported (not a price), excluded items are still shown, output returns both metric and US units plus a citation and page link, and it explicitly does not size structure. It stops short of noting determinism or latency characteristics.

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

Conciseness4/5

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

Purpose is front-loaded in the opening clause and every phrase carries content. The single long, comma-and-parenthetical-heavy sentence is dense though readable, with slight overload in the output enumeration.

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?

For a 9-parameter computational tool with an output schema and full annotations, the description supplies purpose, scope boundary, and a summary of what is returned, which is sufficient. Remaining specifics (unit rules, selection semantics, market effects) are adequately delegated to the rich schema descriptions.

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 100%, so the baseline is 3; the schema already documents detail, market, system, inputUnits, selection, allowances and measurements thoroughly. The description echoes 'from the measurements given' and 'waste allowances' but adds no syntax or format detail beyond the schema.

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

Purpose4/5

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

States a specific verb (works/runs a takeoff) and resource (one whole-job takeoff by id producing a materials list), with concrete examples (slab, deck) and a scope boundary ('It does not size structure'). It does not name the sibling it is distinct from (e.g. get_takeoff vs create_project_file_from_takeoffs), so differentiation is implied rather than explicit.

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

Usage Guidelines3/5

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

Usage is implied: run this to turn measurements into a job materials list. The exclusion 'does not size structure' hints at scope, but the description never says when to choose this over get_takeoff, calculate, or create_project_file_from_takeoffs, nor what prerequisites exist.

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.

Resources