Craft Quantities: construction material calculators

Client proposal from a project, unpriced unless rates given

write_proposal

Read-onlyIdempotent

Writes the client proposal My Project prints: scope by line or trade division, quantities in metric and imperial, assumptions, exclusions, terms, payment stages and the signature block. From a token, a file, calculators, takeoffs or a drawing. "Not priced" unless the reader's own rates are given.

Input Schema

Name	Required	Description	Default
`file`	No	A My Project file (the backup a project-file answer returns, or one the reader exported): its active project's lines, with any hours and rates typed on them.
`name`	No	The project's name on the document.
`intro`	No	A covering note in the contractor's words.
`rates`	No	The reader's own unit rates (the site holds no price), by line id or calculator slug: a number, or { low, high }. A line's own rate in a file stays unless its id is named here.
`terms`	No
`token`	No	A project state token (cqp1.…) from a project-file answer or an update.
`client`	No
`detail`	No	full (the default): the whole answer. summary: the result lines, the citation line and the page only — fewer tokens to read.	full
`market`	No	Optional. 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.
`system`	No	The unit system inputs left out open in, and the one the page link opens in. The answer comes in both.	metric
`drawing`	No	A Construction Canvas drawing (a template, a house form, shapes, drawing commands or a canvas document), as a project file takes it.
`currency`	No	The label the reader's rates are in ("$", "£", "lei"); the market's when left out. A label only: no currency is converted.
`takeoffs`	No	Whole-job takeoffs, each an id and its measurements, as a project file takes them.
`reference`	No
`exclusions`	No
`preparedBy`	No
`validUntil`	No	The date the proposal is valid until, as it is to print.
`calculators`	No	Calculator lines, each a slug and its inputs, as a project file takes them.
`companyName`	No	The contractor's name for the letterhead; blank prints none.
`includeNotes`	No
`showQuantities`	No
`groupByDivision`	No	Group the scope by MasterFormat division.
`paymentSchedule`	No	Stages of payment as the reader sets them; none is suggested.

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

AddedOct 31, 2026

TDQS

A3.8/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 meaningful traits: what sections are included and that the proposal is 'Not priced' unless the reader's own rates are given. No contradiction with annotations.

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 dense sentences, front-loaded with the action and output contents, with no filler. The pricing caveat is placed at the end where it is most likely to be read as a qualifier.

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 23-parameter tool with nested objects and an output schema, the description gives enough to understand the tool's purpose, sections produced, input sources, and pricing behavior. The output schema covers return values, though explicit selection guidance versus siblings remains missing.

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?

With 23 parameters and 70% schema description coverage, the description touches key concepts like trade division grouping, metric/imperial units, exclusions, terms, payment stages, and the five input sources. It does not explain many parameter names or formats (e.g., market, currency, detail, includeNotes), so it adds some value but does not fully compensate for the remaining schema gaps.

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?

The description states a specific verb and resource ('Writes the client proposal') and enumerates the contents (scope, quantities, assumptions, exclusions, terms, payment stages, signature block), so an agent knows it generates a proposal. It does not explicitly differentiate from siblings like write_variation or make_job_sheet, so sibling differentiation is only implicit.

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?

There is no explicit when-to-use or when-not guidance and no alternatives are named. The input-source list ('From a token, a file, calculators, takeoffs or a drawing') implies contexts, but an agent must infer when this tool is the right choice.

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

All Craft Quantities: construction material calculators tools Inspect

Try in Browser

Pay for results, not tokens.Fund a bounty. Let AI agents compete and collaborate to solve your problems.agentbounties.appAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?