Skip to main content
Glama

Craft Quantities: construction material calculators

Open a job or worked example on the Construction Canvas

make_canvas_link
Read-onlyIdempotent

Draws a whole-job takeoff or a worked example at the figures given as a Construction Canvas drawing and returns the link that opens it; the drawing rides in the link's fragment, so nothing is uploaded. Says what the drawing cannot carry. For quantities, not a construction drawing.

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
inputsNoOne step's own input, keyed "<step index>.<input id>" ("3.wastePercent"), each with its unit where it has one.
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
exampleNoOr a worked example the canvas draws, such as attached-deck-built.
figuresNoThe job's own figures by id (a deck's length, a room's height), each length or area with its unit; a count as a number. They follow down every step that reads them.
takeoffNoA takeoff the canvas draws, such as concrete-slab, stud-wall or asphalt-shingle-roof.
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.
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.
includeDocumentNoAlso return the canvas document itself (JSON).

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A3.6/5.0
Behavior4/5

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

Adds real behavioral context beyond the annotations: the drawing is encoded in the URL fragment so nothing is uploaded and no server state is created, which explains the readOnly/idempotent profile. However, 'Says what the drawing cannot carry' is an unresolved fragment that gestures at limitations without stating any.

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 core action and return value are front-loaded, which is good, but the semicolon-chained clauses are over-compressed and one clause is a dangling fragment ('Says what the drawing cannot carry'), costing clarity rather than saving space.

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 stateless link-builder with 11 fully documented parameters, an output schema, and complete safety annotations, the description covers the non-obvious essentials: nothing is uploaded and the link is self-contained. Missing only a hint about link longevity or shareability.

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 every one of the 11 parameters is already documented in the schema. The description only gestures at 'the figures given' without clarifying how figures, measurements, selection, and inputs relate; baseline 3 applies.

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 concrete verb and outcome: it draws a whole-job takeoff or worked example as a Canvas drawing and returns the link that opens it. The closing clause 'For quantities, not a construction drawing' draws a line against drawing-oriented siblings like create_drawing and export_drawing, though it never names them.

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?

Gives one implicit routing rule (use this when you want a shareable rendering of quantities rather than a real construction drawing), but never says when to prefer this over open_in_site_link, run_takeoff, or get_takeoff, which all concern the same takeoff data.

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