Skip to main content
Glama

Craft Quantities: construction material calculators

Compare two options on one job, with the crossover

compare_on_job
Read-onlyIdempotent

Works both sides of a comparison page (LVP vs tile, paint vs wallpaper …) on one job: each side's quantity in both unit systems, allowance, weight and person-hours, the difference, and the crossover as one job figure is swept. Each calculator runs as its page runs it. No prices.

Input Schema

NameRequiredDescriptionDefault
jobNoThe job's figures by field id, each length or area with its unit ("14 ft", {"value": 4.2, "unit": "m"}), a count or pitch as a number, a choice as its option value. Fields left out open at the page's own figure.
sweepNoThe job field the crossover chart sweeps; the page's own when left out.
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.
pointsNoSample points across the swept field's range.
systemNoThe unit system inputs left out open in, and the one the page link opens in. The answer comes in both.metric
comparisonYesA comparison page's slug, such as lvp-vs-tile or paint-vs-wallpaper.
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

A4/5.0
Behavior4/5

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

Annotations already cover read-only, idempotent, non-destructive and closed-world behavior. The description adds useful scope by noting both unit systems, that each calculator runs as its page runs it, the swept crossover, and the important 'No prices' constraint.

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

Conciseness5/5

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

Three compact sentences front-load the operation, then the output scope, then a useful constraint. Every sentence earns its place and there is no filler.

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 complex eight-parameter tool with full schema coverage, annotations and an output schema, the description covers core purpose, output scope and the no-price boundary. It leaves detailed parameter semantics and when-to-use routing to structured fields, so it is not fully exhaustive.

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%, with all eight parameters documented including enums and the nested job object. The description only hints at the sweep via crossover behavior and adds no syntax, defaults or input-unit details beyond the schema, so baseline 3 applies.

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?

States a specific operation: compare both sides of a named comparison page on one job, and enumerates the outputs including units, allowance, weight, person-hours, difference and crossover. The 'comparison page' framing and examples distinguish it from generic calculate siblings.

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?

The purpose and examples imply when to use it, but there is no explicit 'use this when' guidance, no exclusions, and no routing to alternatives such as calculate, calculate_batch or solve_backwards.

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