Skip to main content
Glama

Craft Quantities: construction material calculators

Re-run a worked example with changed figures

run_example_live
Read-onlyIdempotent

Re-runs a worked example with the job's figures changed: each change follows down every step that reads it, each step beside its published figure with the difference, both unit systems, the project lines with offered hours, and a link reopening it. A modelled job; no prices.

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.
exampleYesA worked example's slug, 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.
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.

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?

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed world), and the description adds real context beyond them: changes propagate down every step that reads a figure, results appear beside published figures with a difference, both unit systems are shown, and it is 'a modelled job; no prices.' The no-pricing caveat is exactly the kind of semantic qualifier annotations cannot carry.

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?

One front-loaded sentence with no wasted preamble — the verb and the differentiator lead. It is a dense run-on though, packing five output facets into a comma chain, which costs a little readability.

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

Completeness3/5

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

With an output schema present the description needn't explain return shape, and with full annotation coverage the safety story is told. The remaining decisive gap is sibling routing: run_example sits directly adjacent in the tool list and the description never disambiguates the two.

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 schema already documents detail, inputs, figures, example and inputUnits thoroughly. The description restates the propagation behaviour of figures ('follows down every step that reads it') but adds no new syntax, format, or keying guidance beyond what the schema provides.

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 and resource — re-running a worked example — and adds the differentiator 'with the job's figures changed'. That implicitly separates it from the sibling run_example, but the sibling is never named, so an agent must infer the boundary from the word 'changed' alone.

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 only implied by the phrase 'with the job's figures changed'; there is no explicit statement of when to prefer this over run_example (which presumably runs the example as published). No prerequisites or exclusions are given.

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