Craft Quantities: construction material calculators

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

Annotations already declare read-only, idempotent, non-destructive, closed-world behaviour, so the bar is low. The description still adds real context: the answer comes back in both metric and US units with the inputs used, sources, citation and page link, and prices are deliberately omitted. It also notes that omitted inputs fall back to the calculator page's opening values, though it doesn't discuss failure modes for unknown slugs beyond the schema's 'refused with the accepted ids'.

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

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

Front-loaded with the core action and a compact statement of the return shape, ending on the useful 'No prices' exclusion. The long unit enumeration adds some bulk, but each clause carries information an agent would otherwise have to dig out of the schema.

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

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 need not spell out return values, and annotations cover the safety profile. It still communicates scope, unit handling, default-input behaviour and the price exclusion, leaving only sibling selection and slug discovery unaddressed for a 7-parameter tool with nested inputs.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% and the per-parameter descriptions (slug, detail, inputs, market, system, explain, inputUnits) are already detailed, so a baseline of 3 applies. The description adds only marginal meaning — the unit vocabulary for counts (bags, sheets, studs, tiles, litres, gallons, cubic yards, m³) — without explaining slug discovery or how inputs map to a calculator's schema.

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

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

States a specific verb (computes) and resource (one calculator, by slug) with a concrete scope — the amount of material a job needs — illustrated by bags of concrete and sheets of drywall. The word 'one' implicitly separates it from calculate_batch, but no sibling is named outright.

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

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

The use case (compute a material quantity for a job) is implied clearly enough that an agent can infer when to call it, and 'No prices' excludes a class of content. However, it never says when to prefer calculate_batch, get_calculator, solve_backwards or run_example, so tool selection among close siblings is left to inference.

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

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), so the bar is lower, and the description still adds real behavior: results come back in request order, one refusal does not abort the other runs, and no pricing data is returned. The 'No prices' exclusion is a genuinely useful disclosure that is not encoded in any structured field.

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

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

The purpose and scope are front-loaded in the opening clause, and the trailing 'No prices.' earns its place as a constraint. It is a single long semicolon-chained sentence, which is dense but wastes no words.

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

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

With an output schema and full schema coverage, the description need not explain return values, and it correctly focuses on the non-obvious parts: ordering, partial-failure semantics, and the absence of prices. It omits any mention of the `detail: summary` token-saving mode, which is the one usage-relevant gap.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

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 every parameter, including slug-or-permanent-id, the inputUnits escape hatch, and market/system overrides. The description restates slug/inputs at a high level and adds nothing about the top-level `detail` parameter (full vs summary) or override precedence, so the baseline 3 applies.

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

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

States a specific verb (runs), resource (construction calculator calculations) and a hard scope (up to 25 in one request), which lets an agent separate it from the single-shot `calculate` sibling without opening either schema. It stops short of naming that sibling explicitly, so the differentiation is inferential rather than stated.

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

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

The batching language ('several calculators in one request', 'up to 25') implies when this tool is appropriate versus `calculate`, but there is no explicit when-to-use or when-not-to-use statement and no alternative named. Usage must be inferred from the capability description.

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

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

Annotations already cover safety (readOnly, idempotent, non-destructive, closed-world), so the bar is lower, yet the description adds genuine behavioral context: money is stripped and not judged, and differences are returned as questions rather than verdicts. That framing is not inferable from the schema or annotations. It stops short of describing volume, cost, or latency traits.

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

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

Three sentences, front-loaded with a framing question, then the mechanics, then the important caveat about money and verdicts. Dense but nearly every clause carries information; the parenthetical '(pasted text)' is the only mild redundancy.

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

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

For an 8-parameter tool with nested objects, five enums, and an output schema, the description gives enough to call it correctly and previews the return shape (per-line quantity vs. calculator range, missing/extra lines, questions to ask). The output schema carries the detail, so nothing critical is missing, though the 75-value job enum and selection/measurements interplay are left entirely to the schema.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

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 job, quote, detail, market, system, selection, inputUnits, and measurements. The description reinforces that the quote arrives as pasted text and that prices are tolerated, but adds no syntax or constraint detail beyond the schema. Baseline 3 applies.

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

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

States a clear verb and object ('checks a contractor's quote against the reader's own job') and immediately distinguishes the operation from sibling quote tools like import_quote or create_supplier_quote_request by framing it as a verification against calculator ranges, not a capture or a request. The opening question plus the enumerated outputs make the purpose unmistakable.

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

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

Usage is implied by the mechanics: the caller must supply pasted quote text plus a job, so the agent can infer when it applies. However, it never explicitly says when to prefer this over import_quote or when the tool is inappropriate, and no prerequisites are stated.

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

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 genuinely non-obvious context: the grouping comes from 'the site's own keyword rule over each line's calculator or words,' and the result is advisory rather than authoritative. It does not discuss failure modes or rate limits, which keeps it out of the top band.

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

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

Two sentences, front-loaded with the verb and the standard, and the trailing disclaimers ('not a specification,' 'no Uniclass or NRM,' 'no prices') each carry real information. The first sentence's stacked parentheticals are dense enough to slow reading slightly, so not a 5.

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

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

An output schema exists, so return values need no explanation, and the description covers inputs, the classification mechanism, and the tool's limits. What remains implicit is how the three input modes interact if more than one is supplied and what an empty or unclassifiable line yields.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3, but the description adds meaning the schema does not state outright: that `lines`, `calculators`, and `token` are alternative ways of supplying the same material set. It does not explain the `detail` enum beyond what the schema already says.

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

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

States a specific verb (groups) applied to a specific resource (materials list / bill / takeoff / plan / project) and names the classification standard (CSI MasterFormat 2018). It also enumerates the accepted input forms (lines, calculator slugs, project state token), which no sibling tool does, so an agent can distinguish it immediately.

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

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

Explicitly frames the output as 'a suggested grouping, not a specification' and rules out Uniclass or NRM grouping and prices, which tells the agent when this tool is and is not the right fit. It stops short of naming an alternative tool for those excluded standards, so routing guidance is incomplete but clearly present.

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

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.

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.

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.

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.

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.

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.

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint=false and destructiveHint=false, so the safety profile is covered without description help. The description does add real behavioral context by naming the return payload (converted value plus the factor) and tying results to the site's calculator factors, but it omits anything on failure modes, unknown units, or limits.

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

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

A single front-loaded sentence with the core verb first and the example and return value trailing. It is efficient, though the final clause stacking factor provenance and return shape makes it slightly dense.

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

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

An output schema exists, so the description is not obliged to explain return values, and the annotations carry the safety profile. Still, for a five-parameter tool with 40% schema coverage, the lack of unit-format and dimension-disambiguation guidance leaves gaps an agent would hit in practice.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is only 40% across five parameters, so the description is expected to compensate and does not. It illuminates 'value', 'from' and 'to' only through an example, and says nothing about valid unit strings (the 40-character maxLength), how 'dimension' resolves ambiguous units, or how 'detail' changes output.

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

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

States a specific verb and resource (converts a value from one unit to another) with a concrete example (2 m³ to cubic yards). It also hints at the differentiating trait versus generic calculators by promising 'the exact factor the site's calculators apply,' though it never names calculate or solve_backwards, so the sibling distinction is only implied.

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

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

There is no statement of when to prefer this tool over calculate, solve_backwards, or the many other numeric siblings, nor any prerequisite or exclusion. An agent must infer usage entirely from the tool name.

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

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

Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so the safety profile is covered. The description adds the capability boundary ('does not size structure') and enumerates return artifacts, but says nothing about whether the drawing is persisted, what authorization is needed, or what happens on invalid geometry beyond what the schema states. There is mild tension between 'create/draws' and readOnlyHint=true, but the description's 'returns ... a link ... and a file' framing is consistent with a non-persisting generator.

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

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

Purpose is front-loaded in the opening clause, but the single sentence then runs long enumerating return values that the output schema already describes. Splitting out the 'does not size structure' boundary and trimming the output list would make it tighter.

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

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

Given 11 optional top-level parameters, deeply nested objects, and no required fields, the critical missing piece is guidance on input-mode selection and precedence — an agent cannot tell from the description whether layout and commands can be combined or which wins. The output side is fully covered by the output schema, so that omission is not a gap.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% and an output schema exists, so the baseline of 3 applies. The description names the six alternative input channels, which mirrors the top-level property names but adds no precedence, unit, or interaction semantics beyond what the schema documents.

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

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

States a specific verb and resource ('Draws one plan on the Construction Canvas') and enumerates the alternative input forms it accepts (shapes, layout rooms, house figures, commands, document, template). What it produces is spelled out too. It does not, however, distinguish itself from close siblings such as create_project_file_from_drawing or export_drawing, which an agent must infer.

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

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

Usage is only implied by listing the accepted input modes; the agent is never told whether shapes, layout, house, commands, document and template are mutually exclusive or what happens when several are supplied. The one explicit boundary — 'It does not size structure' — is genuinely useful because it routes structural sizing elsewhere, but it is the sole guideline.

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

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

Annotations already declare readOnly/idempotent/non-destructive/closed-world, and the description corroborates that with genuinely new context: 'Nothing is stored or sent; no prices' clarifies there are no side effects or pricing data, and 'Each line is computed as the site's page adds it' explains how values are resolved. It stops short of describing failure behavior or limits (max 50 lines) beyond what the schema already says.

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

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

Three short sentences, front-loaded with the action and resource, then workflow, then the safety/no-cost guarantee. Every sentence carries distinct information with no repetition of the structured fields.

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

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

An output schema exists, so return values need not be explained, and annotations cover the safety profile while the schema fully documents the five parameters. The description supplies the workflow framing (compute-per-line, restore on the site) that ties the inputs to the artifact; only minor gaps like limits and error behavior remain, and the schema covers those.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so every parameter (name, detail, market, system, calculators and nested fields) is already documented in the schema, including enums, defaults and unit formats. The description only restates the calculators parameter parenthetically and adds no format or fallback detail 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.

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

The description gives a specific verb and resource ('Creates one My Project backup file from a list of calculator lines') and defines the input unit ('each a calculator slug and its input values'), which separates it from the drawing/house/plan/takeoffs siblings by input mode. It never names those alternatives directly, so the differentiation relies on the name and a single clarifying clause rather than explicit contrast.

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

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

Usage is implied rather than stated: 'the reader restores the file on craftquantities.com as a new project' tells the agent the outcome and hence the general intent, but there is no when-to-use, no when-not-to-use, and no reference to the sibling create_project_file_from_* tools. The agent must infer the choice from the tool name alone.

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

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), so the bar is lower. The description adds genuinely useful non-obvious context: the file is a backup the site's canvas reopens and restores as a new project, and 'Nothing is stored or sent; no prices' preempts the natural worry that 'creates a file' implies persistence or network transmission.

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

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

Three short sentences, front-loaded with what is produced, then the restore destination, then the no-side-effects caveat. No padding, though the middle sentence about the canvas reopening is somewhat redundant with the first.

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

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

An output schema exists, so return values need not be explained, and annotations carry safety. However, for a tool whose required 'drawing' input spans four very different modes (house form, shapes, commands, canvas document), the description never enumerates them, leaving the agent to discover the input branches entirely from the schema.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the schema already documents name, detail, system and the whole drawing tree. The description adds no parameter syntax or format detail beyond describing the input as 'the drawing,' which is the baseline expectation when the schema does the heavy lifting.

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

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

It names a specific verb and artifact: 'Creates one My Project backup file from a Construction Canvas drawing.' The input source (a drawing) is clear, but it never distinguishes itself from the many sibling generators (create_project_file_from_plan, _from_house, _from_calculations, _from_takeoffs), leaving the agent to infer the boundary.

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

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-to-use guidance, and no named alternative. The only usage signal is implicit in the input source ('from a drawing') plus the downstream note that the reader restores it on craftquantities.com — this does not tell the agent how to choose between the five create_project_file_* siblings.

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

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

Annotations already declare readOnly, idempotent and non-destructive, and the description reinforces this with 'Nothing is stored or sent; no prices' and explains the downstream flow ('the reader restores the file on craftquantities.com'). That adds genuine behavioral context beyond the annotations, though it does not spell out output/size limits.

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

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

Three short sentences with the core action front-loaded and no filler. The trailing 'no prices' fragment is slightly telegraphic but not wasteful.

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

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

An output schema exists, so return format need not be described, and the description covers the transformation, its provenance and its lack of side effects. It could say more about the two-house case (lines without drawing) or unit behavior, but nothing critical is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

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 name, detail, houses and system. The description adds only high-level framing ('the house's lines, and its drawing') and does not clarify any individual parameter, so the baseline 3 applies.

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

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

States a specific verb and resource ('Creates one My Project backup file') plus the exact input source ('from a House Estimator form'), which implicitly separates it from the from_plan/from_drawing/from_calculations siblings. It is clear without being an explicit side-by-side differentiation.

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

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

Usage is only implied by the source ('from a House Estimator form'). It never states when to prefer this over create_project_file_from_calculations or the other create_project_file_* siblings, nor any prerequisites or exclusions.

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

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

Annotations already declare readOnly/idempotent/non-destructive/closed-world, and the description usefully reinforces this with the non-obvious 'Nothing is stored or sent; no prices', which resolves the apparent tension between a verb like 'Creates' and a read-only hint. It adds real behavioral context beyond the annotations, though it does not describe the returned file/response shape.

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

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

Three tight sentences, front-loaded with the action and the plan-shape scoping; no filler. The clause about 'the site's planner saves them' is slightly roundabout but still informative.

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

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

Given a rich input schema (100% coverage), an output schema, and strong annotations, the description supplies what structured fields cannot: the side-effect profile and the downstream purpose of the file. Missing only the tool-selection guidance that would make it fully self-sufficient.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

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 description's 'one planned space, or several spaces and a roof' mirrors what the schema already states for the 'plan' parameter and adds no format or unit details beyond it.

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

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

States a specific verb ('Creates') and resource ('one My Project backup file') plus the input source ('from a room plan'), which is exactly what distinguishes it from create_project_file_from_calculations, _from_drawing, _from_house and _from_takeoffs. It also characterizes the plan shape (one space, or several spaces and a roof). It never explicitly names those siblings, so it falls short of a full 5.

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

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

The description never says when to choose this over the other 'create_project_file_from_*' tools or any sibling; there is no when/when-not guidance and no prerequisites. It explains what the output does downstream but leaves tool selection entirely to inference from the name.

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

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

Annotations declare readOnly/idempotent/non-destructive, and the description usefully adds context the annotations cannot convey: nothing is stored or sent, no prices, and the resulting file is restored by the reader on craftquantities.com as a new project — which also reconciles the seemingly odd readOnlyHint on a 'create' tool. It omits the 10-takeoff cap and any note on determinism/repeat calls.

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

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

Three short sentences, front-loaded with the core action, and each sentence carries distinct information (what it makes, how takeoffs are processed/restored, and that nothing is persisted). Some phrasing ('as its page commits them') is dense domain jargon, but no sentence is wasted.

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

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

With an output schema present and full schema description coverage, the description need not explain returns or parameters; it covers the action, the persistence semantics, and the restore path. It is only mildly incomplete in not linking takeoff ids to their producing tools or noting the array limits.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

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 name, detail, market, system, leaveOut, selection, allowances, inputUnits and measurements. The description only restates the takeoffs shape ('each a takeoff id and its measurements') and adds nothing about the optional parameters, so the baseline 3 applies.

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

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

The description states a specific verb and resource ('Creates one My Project backup file from a list of whole-job takeoffs') and names the input source, which is what separates it from the create_project_file_from_calculations/drawing/house/plan siblings. It does not explicitly call out those siblings, so the differentiation rests partly on the tool name.

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

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

It explains the mechanics ('each takeoff's lines are worked as its page commits them') but never says when to choose this over the other create_project_file_* variants, nor what prerequisite a takeoff id must satisfy (e.g. coming from run_takeoff/get_takeoff). No when-not guidance and no stated alternatives.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true and destructiveHint=false, setting a low bar. The description still adds real value by resolving the tension created by the 'to suppliers' name: 'it carries no price and sends nothing to anyone', telling the agent this never dispatches anything externally.

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

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

Front-loaded with the verb and resource, and the second short sentence carries the key behavioral caveat. The long parenthetical listing sources is dense but every clause is on-topic, so it stays reasonably tight.

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

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

An output schema exists, so return values need not be explained, and annotations cover the safety profile. The description says what is created and that nothing is sent, leaving only sibling routing and downstream handling of the created quote unaddressed.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 83%, so the schema already documents note, items, detail, market, project and currency well. The description's mention of 'Markdown to paste, a CSV, the site's link ... and a My Project file' does not map onto any of those parameters, adding little meaning to the actual argument surface.

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

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

States a specific verb (creates) and resource (a request for quote) plus the inputs it accepts (materials list or bill of materials from a takeoff, house, plan, calculation, or the reader's own). It does not name or distinguish itself from siblings like import_quote or check_quote, so it stops short of a 5.

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

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

The description explains what the tool produces but gives no when-to-use guidance, no prerequisites, and never names an alternative sibling (e.g. import_quote or check_quote) or the condition that would select it. An agent must infer the usage context on its own.

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

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), so the bar is lower. The description earns credit by disclosing output behavior beyond that: it returns ranked candidate causes with discriminators and an ordered check list, modifies its breadth on ambiguous input, and explicitly refuses a verdict ('does not say which cause it is') — a crucial expectation setter.

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

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

Front-loaded with the verb and resource, and every clause carries information — the matched resource, the returned content, and the ambiguity caveat. It is a single run-on sentence, which slightly hurts scanability, but there is no filler.

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

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 re-explain return values, and it still sketches the shape of the answer. Combined with 100% parameter coverage and full annotation coverage, the definition is complete enough to invoke correctly; only routing guidance versus siblings is thin.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, and each of the four parameters (symptom, limit, detail, market) already carries a rich inline description, so the schema does the heavy lifting. The description adds no parameter-level detail (nothing about the limit=3 cap, the full/summary modes, or the market effect), which is acceptable at this coverage but adds no extra value.

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

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

Specific verb+resource: matches a plain-words building defect (crack, damp, leak, tripping breaker) to the site's diagnosis pages. It also names the concrete payload (candidate causes, distinguishing signs, ordered checks, when to call a professional), which no sibling tool offers.

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

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

Usage context is implied by 'described in plain words' and the ambiguity note ('ambiguous words return candidates'), so an agent can infer it wants free-text symptom input. But no alternatives are named and no when-not guidance is given, e.g. what to do when a calculator-style sibling (get_calculator, calculate) would be the better fit.

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

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

With readOnly/idempotent/non-destructive annotations already covering the safety profile, the description adds real behaviour: the precedence rule (hours typed on the line, else a rate band for its quantity, else the reason for none), the crew-days computation, and the explicit 'Hours only: no prices' scope limit. It still doesn't say what happens when no source argument is supplied, which matters for a tool with zero required parameters.

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

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

Three short sentences with the output stated first, then the computation precedence, then the scope exclusion — front-loaded and waste-free. The compressed phrasing ('else the reason for none') is dense but each clause carries information.

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

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

For an 11-parameter tool with deep nested objects, the description suffices: it says what is produced, how each line's hours are derived, and that prices are excluded, while the output schema covers the response shape and annotations cover safety. The one real gap is that no-argument behaviour is never described, despite every parameter being optional.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so all 11 parameters are already documented individually and the baseline of 3 applies. The description's source list is ordered as alternatives ('a token, a file, calculators, takeoffs or a drawing'), hinting at mutual exclusivity the schema never states, but it adds no guidance on combining or omitting them.

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

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

It names the exact computed quantity ('Estimated person-hours on each line of a project') plus the secondary output (the project's crew-days), so the resource and result are unambiguous. 'Hours only: no prices' draws a boundary against pricing siblings, but neither that nor any other tool is named.

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

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

The sentence 'From a token, a file, calculators, takeoffs or a drawing' implies which inputs are accepted and that they are alternatives, which is useful routing. However, there is no explicit statement of when to call this instead of calculate, run_takeoff, estimate_house or create_project_file_from_* — the boundary with siblings is left to inference.

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

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

Annotations already declare readOnlyHint, idempotentHint, non-destructive and closed-world, so the safety profile is covered. The description adds genuine context beyond that: the tool is a counting/estimation pass that does not perform structural design and returns no pricing, and it details what the response body contains. It does not discuss limits or error behavior, but there is little else to disclose for a deterministic computation.

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

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

Two sentences, purpose front-loaded ahead of the output description and the two exclusions. The first sentence is dense with parentheticals but every clause carries information; nothing is redundant filler.

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

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

An output schema exists, so return values need not be described, yet the description still frames the result shape usefully. Annotations cover safety, and the description covers scope and functional limits. For an 11-parameter nested-object tool the coverage is solid, with only per-parameter unit/dimension behavior left largely to the schema.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 64% across 11 params, so the schema does much of the work. The description contributes a conceptual map of the inputs ('footprint, walls, roof, openings'), which hints at the values, selection/roofSelection, and opening parameters, but it adds no per-parameter syntax or unit guidance beyond what the schema already provides.

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

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

Specific verb (estimates) plus a tightly scoped resource: materials for one rectangular house, one or two storeys, from enumerated input groups (footprint, walls, roof, openings). It also states the output contents (quantities with what to order, assumptions, storey plans, labour hours). An agent can distinguish it from create_drawing ('does not design a structure') and from quoting tools ('No prices') without opening the schema.

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

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

Clear about what the tool is for and where its boundary lies, with two explicit exclusions that implicitly route the agent elsewhere: 'It counts; it does not design a structure. No prices.' No sibling is named directly, so the routing to create_drawing or check_quote is inferred rather than stated.

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

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 usefully adds fidelity behavior ("as the canvas's own download writes them"), the DXF CQ-* layer convention, SVG being one plan per level in millimetres, IFC4 quantity sets, and the large-file fallback ("a file too large to return is rebuilt from the drawing's link"). Meaningful behavioral context beyond structured fields.

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

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

A single front-loaded sentence that leads with the verb and resource; nearly every clause earns its place by adding a distinct output detail. It is slightly run-on with multiple semicolon-joined ideas, but there is no filler.

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

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

For a 12-parameter tool with full schema coverage, an output schema, and rich annotations, the description supplies the extra output-format and fallback context an agent needs. The main gap is routing advice among the many sibling tools, which keeps it from being fully complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so all 12 parameters are already documented in the schema, which is the baseline for a 3. The description restates the format families (dxf/svg/ifc) and input sources but adds no syntax or constraints beyond what the schema already carries.

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

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

States a specific verb and resource ("Exports a Construction Canvas drawing") and enumerates the accepted drawing sources (template, shapes, layout, commands, house figures, document) plus the three output formats, so its job is unambiguous. It stops short of naming how it differs from siblings like create_project_file_from_drawing, but the format-level detail is distinctive.

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

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

The description says what it produces but never states when to reach for it over alternatives (e.g. create_project_file_from_drawing or open_in_site_link). The list of input sources implies what can be passed, but there are no conditions, prerequisites, or exclusions to guide selection.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is fully covered. The description's added content is essentially return-value shape, which is already carried by the existing output schema, so it contributes little behavioral context beyond structured data.

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

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

A single front-loaded sentence that states the return and its constituent parts, with no wasted preamble. The trailing colon list is slightly long but each item is informative rather than filler.

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

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

An output schema exists, so return values need not be explained, and annotations cover safety — but in a 27-sibling toolset the definition omits which page types this generic fetch is for versus the specialized getters. For a tool whose main risk is misrouting, that gap keeps it at minimum viable.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% and the single 'id' parameter is richly documented with example values in the schema itself. The description's 'identified by its id' restates that without adding format or validation meaning, so the baseline 3 applies.

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

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

States a concrete verb ('Returns the full text') and an unambiguous resource ('one Craft Quantities page, identified by its id'), and even sketches the content shape (what it works out, inputs/measurements with units, opening values, sources). It does not, however, differentiate itself from page-type-specific siblings like get_calculator, get_takeoff, or get_sources, whose overlap is left unaddressed.

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

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

No when-to-use or when-not-to-use guidance. With 27 siblings, several of which (get_calculator, get_takeoff, get_sources) appear to retrieve the same underlying page data in a narrower form, an agent gets no rule for choosing 'fetch' over them. Usage is only implied by the generic name.

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

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

Annotations already declare readOnlyHint, idempotentHint and non-destructive, so safety is covered. The description adds genuine value by disclosing the shape of the answer (part ids, grain, cut order, offcuts, edge banding) and by scoping it with 'Geometry only', which tells the agent this does not price or quote. It stops short of disclosing defaults, unit behavior, or what the nesting step does when parts do not fit.

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

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

It is compact and front-loads the core purpose, but it is one long run-on sentence built from colon chains, and 'the blank' is repeated in both halves ('the blank with scribe and bow, then the blank and any other parts nested'). A tighter two-sentence split between measurement and nesting would read better.

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

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

This is a 27-parameter tool with nested objects, eight enums and defaults layered on defaults. An output schema exists so return values need no explanation, but the description never explains the measurement model (span, measuredAt, leftAngle/rightAngle) or when to reach for this versus fit_worktop_run, leaving an agent to reconstruct the whole workflow from the schema alone.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 81%, so the schema already carries most parameter meaning and the baseline would be 3. The description still adds semantics the schema does not: it frames scribe and bow as inputs that shape the blank, and ties grain, offcuts and edge banding to the nesting output, which helps the agent understand which parameters feed which part of the answer.

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

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

The description names the resource (worktop, shelf or panel between walls that are not square) and enumerates the outputs, which makes the purpose inferable, but it is a noun-phrase fragment with no verb and it never distinguishes itself from near-identical siblings like fit_worktop_run or scribe_template. An agent can guess what it produces but not why it should pick this one.

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

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

There is no when-to-use, when-not-to-use, or alternatives guidance anywhere. With fit_worktop_run, scribe_template and optimise_cuts in the sibling list, the absence of any routing sentence is a real gap.

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

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

Annotations already declare this as a read-only, idempotent, non-destructive, closed-world computation, so the description is not burdened with safety disclosure. The description adds some behavioral context by stating that the tool models the Construction Canvas cut, handles joints and nesting, and is 'Not sized.' However, it does not clarify what 'Not sized' implies operationally or how defaults are applied across the many parameters.

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

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

The description is a single dense sentence that front-loads the core purpose and lists the outputs efficiently. It has minimal waste, though the long sentence and ambiguous 'Not sized' tail slightly reduce clarity.

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

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

The tool has 17 parameters, nested objects, and an output schema, so the return values need not be explained. Still, the description is thin for such a complex tool: it does not explain how to structure faces/corners or clarify the meaning of 'Not sized' in relation to the inputs. It is adequate given the rich schema but not complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 88%, so parameter semantics are largely handled by the schema. The description adds only high-level references to joints, banding, cut order, and the 'Not sized' constraint, without enriching the meaning of key parameters like faces, corners, start, finish, or stock. Baseline 3 is appropriate when the schema does the heavy lifting.

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

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

The description names the specific resource (a worktop run along several wall faces) and enumerates what the tool produces: true shapes, butt/mitre joints, joined straights, front run, free ends, nested blanks with cut order and banding. It is clearly more than a restatement of the name. It does not, however, differentiate the tool from plausible siblings such as plan_room_trim, miter_chart, or fit_panel.

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

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

There is no explicit guidance on when to use this tool versus alternatives. The phrase 'Not sized' is the only usage-oriented hint, and it is ambiguous rather than a clear exclusion or prerequisite. An agent must infer the applicable scenario entirely from the name and description.

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

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

Annotations already declare readOnlyHint, idempotentHint, and non-destructiveness, so safety is covered. The description adds meaningful context beyond that: the dataset is CC BY 4.0, it is built from the site's calculator test vectors, and it returns a download link and citation guidance. It does not, however, disclose pagination bounds or item counts.

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

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

The main purpose is front-loaded in the first clause, followed by item contents and the paging/citation note. It is dense but every element (units, tolerance, citation, download link) earns its place; the trailing fragment is slightly abrupt but not wasteful.

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

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

With an output schema present, return values need not be explained, and the description covers content, paging granularity, unit systems, licensing, and citation. The only minor gap is the absence of guidance on tool choice versus similar read tools, which is not strictly required for correct invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already fully documents page, detail, and calculator, including defaults and the slug pattern. The description reinforces the page-vs-calculator scoping but adds no format or syntax detail 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.

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

States a specific verb ('Returns items of') and a precisely named resource (the Construction Quantities Benchmark), then enumerates exactly what each item contains (inputs, prompt, expected answer, tolerance, worked steps). This distinguishes it clearly from siblings like get_calculator, get_example, and get_sources.

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

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

The description implies the two usage modes ('A page of calculators at a time or one calculator's items'), which maps to the page vs calculator parameters, but it never states when to prefer this tool over related siblings such as get_calculator or get_example, nor any exclusions.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds genuinely new behavioral context not in annotations: it lists exactly what is returned (units in metric and US, version, page, citation) and asserts it performs no computation, clarifying it is a pure lookup.

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

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

A single dense sentence front-loads the core action and ends with the differentiator 'It computes nothing'. Every clause is substantive, though the field enumeration is somewhat list-heavy given an output schema already exists.

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

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

With an output schema present, the return-field enumeration is arguably redundant, but nothing an agent needs to call the tool correctly is missing: slug identification, the detail-mode trade-off, and the no-computation caveat are all present. Only the explicit sibling routing is absent.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%: the slug pattern/example and the detail enum (full vs summary token trade-off) are fully documented in the schema. The description confirms slug-based identification but adds no syntax or format meaning beyond what the schema already provides, so baseline 3 applies.

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

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

States a specific verb+resource ('Returns the input fields of one calculator') and enumerates the returned content. Critically, 'It computes nothing' cleanly distinguishes it from the sibling 'calculate', so an agent can separate the two without opening schemas.

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

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

'It computes nothing' implies the agent should not use this to compute and should look elsewhere (e.g., calculate), giving clear context. However, it never explicitly names the alternative tool or states the positive 'use this when you need field metadata' condition, so routing is inferred rather than spelled out.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, openWorldHint=false and destructiveHint=false, so the safety profile is fully covered without the description. The description adds a content outline rather than behavior — it says nothing about failure modes for an unknown slug, which is the one behavioral detail an agent would want.

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

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

A single sentence with the key identifier front-loaded ahead of the content list. The trailing enumeration is slightly long, especially since an output schema already exists to describe the return shape, but nothing is padded or redundant.

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

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

With annotations covering safety and an output schema covering the return shape, the description only needs to place the tool, which it does. The residual gap is sibling disambiguation against run_example and any note on unknown-slug behavior.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

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 both the slug pattern/example and the full/summary enum with its token trade-off. The description only echoes that the example is identified by slug and never mentions the detail parameter, so it adds nothing over the schema. Baseline 3 applies.

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

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

States a specific verb and resource — "Returns one worked construction estimate from the site, identified by its slug" — and enumerates the payload (measurements, ordered steps, calculator per step, pinned figure, waste). It does not, however, distinguish itself from the close sibling run_example, which an agent could plausibly confuse with it.

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

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

Usage is only implied: an agent infers "use this to read one stored example by slug." There is no explicit when-to-use, no exclusion, and no pointer to run_example or get_calculator, which is the main ambiguity in this sibling cluster.

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

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

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds real behavioural context beyond that: cardinality (one illustration per guide/comparison/diagnosis etc.) and the fact that glossary, methods, policies, standards and tools share a single plate rather than having per-page art. It stops short of saying what happens when a page has no illustration assigned.

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

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

Two sentences, front-loaded with the return payload before the per-family cardinality rule; no filler. The compressed phrases 'shared plate' and 'solve-backwards question' cost a little clarity for the token saving but stay readable.

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

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

With a full output schema and 100%-covered input schema, the description carries little structural burden, and it still supplies the family/cardinality rule an agent needs to pick parameters correctly. Only the empty-result case is unaddressed, which is a minor gap for this complexity.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline would be 3, but the description adds genuine meaning: it maps the family enum values to their cardinality, explaining that the shared-plate families return the same drawing regardless of slug. That clarifies the interaction between the two parameters in a way the schema does not.

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

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

The first clause names a specific verb and resource — 'Returns the topic illustration a page of the site carries' — and enumerates the payload (SVG address, subject, licence). It is distinguishable from mutation siblings like create_drawing or export_drawing, though it never names the read/retrieval alternatives (fetch, open_in_site_link) it sits beside.

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

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

Usage is only implied: 'the topic illustration a page ... carries' suggests calling it when you need the artwork for a given page. There is no explicit when-to-use, when-not-to-use, or reference to a sibling for the same need, so the agent must infer the selection rule.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety and side-effect profile is fully covered without the description. The description adds a content inventory of the returned fields, which is mildly useful, but says nothing about failure modes for an invalid kind or about the detail-mode tradeoff already in the schema.

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

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

A single sentence, front-loaded with the verb and resource, with no filler or restated title. The trailing list of returned artifacts is dense but every clause carries content.

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

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

With an output schema, full parameter descriptions, and complete annotations, most structural gaps are already filled elsewhere. The remaining gap is routing: nothing explains the relationship between this tool and the plan_room/plan_project siblings, which is the one thing an agent still needs.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% and both parameters carry enum descriptions, so the schema does the heavy lifting. The description only echoes "one kind of space" and does not add format or selection guidance beyond the enum values already documented.

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

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

The description gives a specific verb ("Returns") plus a concrete resource ("the room planner's fields for one kind of space") and enumerates the payload contents (figures, surfaces, finish ids, scope questions, rows). It is clear on its own, but it never distinguishes itself from similarly-named siblings such as plan_room, plan_project, or get_calculator.

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

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

There is no when-to-use or when-not-to-use guidance and no alternative tool is named. An agent reading this cannot tell why it would call get_planner rather than plan_room or plan_project, which is a real risk given the overlapping planning vocabulary in the sibling list.

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

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

Annotations already declare readOnly, idempotent, non-destructive, closed-world behavior, so the safety profile is covered. The description adds a genuine behavioral guarantee beyond that: the tool returns only sources the calculator actually cites, which tells the agent the result is a faithful subset rather than an enriched bibliography. It says nothing about size, pagination, or failures, keeping it short of a 5.

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

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

Three short sentences, front-loaded with a concrete question that frames the purpose before the payload list. The rhetorical opener is a small stylistic cost rather than filler, and the closing fidelity clause earns its place as a scope constraint.

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

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

An output schema exists, so the shape of the returned sources and citations need not be restated, and annotations carry the safety profile. The description covers what is returned and its fidelity constraint; only the prerequisite that the slug must reference an existing calculator is left implicit, a minor gap.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%: both slug and the full/summary detail enum are documented in the schema itself with defaults and meaning. The description adds no parameter-level information (the citation-format list describes output, not input), so the baseline 3 applies.

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

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

States a specific verb and resource ('Returns a calculator's sources as it cites them') plus the exact payload: codes/standards, standards pages, and citation formats (plain, APA, Harvard, BibTeX). This clearly separates it from get_calculator, get_example, and the create_* siblings, which deal with the calculation or its output rather than its provenance.

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

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

The leading question ('Where does a figure come from, and how is it cited?') implies the provenance/citation use case, and 'It adds no source the calculator does not cite' sets an expectation of scope. However, it never states when to prefer this over get_calculator or how to reach it, so the usage trigger is inferred rather than explicit.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and a closed world, so the safety profile is fully covered structurally. The description adds useful shape about what is returned (units, opening figures, build-up choices, calculators, exclusions), but says nothing about sizing, pagination or how it behaves for an unknown id.

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

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

A single dense sentence with the identifier and the return contents front-loaded; every clause carries information and there is no filler. It is slightly long for one sentence but nothing is wasted.

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

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

With annotations covering safety and an output schema covering the return shape, the description only needs to frame the lookup, which it does. Missing is any linkage to the execution-side sibling run_takeoff, which would help an agent pick correctly between the two.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so both parameters (takeoff id and the full/summary detail toggle) are already documented in the schema; baseline 3 applies. The description reinforces the id lookup but never mentions the detail parameter, so it adds no meaning beyond the schema.

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

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

States a specific verb and resource ('Returns the measurements one whole-job takeoff needs, identified by its id') and enumerates what the payload contains, so the agent knows exactly what it gets. It does not, however, distinguish itself from the sibling run_takeoff or create_project_file_from_takeoffs, which is the main gap at this level.

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

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

No when-to-use statement, no prerequisites, and no mention of alternatives such as run_takeoff (which presumably executes a takeoff) or create_project_file_from_takeoffs. The agent must infer from the name alone when this is the right call.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint=false and destructiveHint=false, so the safety profile is covered. The description adds genuinely useful behavior: it self-checks its arithmetic and that prices are the reader's own figures, not site-derived. It does not address failure modes for unparseable quotes or input limits.

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

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

Two sentences, with the core action front-loaded and the price-provenance caveat second. Slightly loose phrasing ('the reader has, prices and all') costs a little, but there is no filler.

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

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

An output schema exists, so return values need not be explained. For a read-only, deterministic conversion tool the description covers the action, the arithmetic check, and the provenance of figures; only error/limit behavior is unstated.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 67%: quote, detail, market and currency carry descriptions, while name and supplier are undocumented in both schema and description. The line about prices being the reader's own figures loosely ties to the currency parameter, but the description otherwise adds no parameter semantics beyond what the schema provides.

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

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

States a specific verb and resource: turning a supplier's or builder's quote into a My Project file/estimate, with an explicit analogy to the site's 'Quote to Estimate'. It is clear what the tool does, though it never names or distinguishes itself from near siblings like check_quote or create_project_file_from_takeoffs.

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

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

The description implies you call it when a reader has a quote in hand, but gives no when-to-use criteria, prerequisites, or explicit routing against alternatives such as check_quote (which presumably validates rather than converts). No exclusions are stated.

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

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

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so safety is covered. The description adds real behavioural context beyond that: two drawing formats produced, weight reported only conditionally ('where the site's calculator carries the size'), lap defaulting to the calculator's own value, and the explicit scope limit that it performs no design or code checking.

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

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

Front-loaded with the verb and scope, followed by an efficient output enumeration and a one-line boundary statement. The single long sentence listing outputs is dense but every item earns its place; no filler or repetition.

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

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

An output schema exists and the input schema is fully described, so the description does not need to explain returns or parameters. Given the tool's complexity it covers scope, outputs and the design/quantity boundary well; the only omission is any hint about default resolution between the redundant spacing vs lengthwise/widthwise count inputs.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% across all 15 parameters, including nested lengthwise/widthwise/chairs objects and five enums, so the schema already carries the semantics. The description only loosely gestures at the inputs (bar size, spacing, cover, 'bars each way', lap) without adding format or edge-case detail 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.

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

States a specific verb and resource ('lays out reinforcing bars in a rectangular slab or footing') and enumerates the concrete outputs: bars each way, bar lengths, total length with lap, stock sticks, weight, SVG and DXF. The closing boundary ('a quantity layout, not a design: it does not size structure or check a code') cleanly separates it from calculate/design-oriented siblings.

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

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

It gives a clear exclusion ('not a design... does not size structure or check a code'), which tells the agent when this tool is the wrong choice. However, it never names the alternative to use instead (e.g. calculate or create_drawing), so routing is implied rather than explicit.

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

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

Annotations already establish a safe, read-only, idempotent, closed-world operation. The description adds meaningful behavioral context beyond that: money is stripped out, no total or ranking is produced, and the output covers inclusion status, additions, and follow-up questions. It does not describe return format or pagination, but the output schema exists.

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

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

The description is compact and front-loads the main action before listing per-line details. The sentence is dense with semicolons but every clause contributes to understanding the comparison output.

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

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

For a complex tool with eight parameters, nested objects, a full output schema, and annotations, the description covers the core behavior and the important money-removal caveat. It is somewhat thin on when to choose this over sibling tools, but the structured fields fill in the rest.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

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 all eight parameters thoroughly. The description adds little beyond what the schema provides, beyond reinforcing 'both systems' and the two-to-six quote scope. Baseline 3 is appropriate when the schema carries parameter semantics.

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

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

The description states a specific action ('Levels... quotes') and resource ('contractors' quotes for one job against the job's own lines'), and it details the per-line dimensions compared. It does not explicitly distinguish itself from siblings such as check_quote or compare_on_job, so it stays short of a 5.

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

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

The context implies this is for comparing two to six quotes for a single job line by line, and the schema enforces the quote count. However, there is no explicit when-to-use guidance, no exclusions, and no mention of alternatives like check_quote or compare_on_job.

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

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.

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.

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.

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.

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.

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.

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

Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so the safety profile is covered. The description adds one genuine behavioural fact beyond that – 'no prices' in the output – but most of the rest restates what the output schema already documents, so the marginal value is modest.

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

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

One dense sentence, front-loaded with the purpose and then listing contents in a sensible order; the closing 'no prices' constraint lands last where it is easy to catch. Some phrasing ('the van', 'the build-up') is idiomatic at the cost of precision, but there is no padding.

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

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

With a full output schema, rich annotations and 100% schema coverage, the description needs only to frame what the tool is for and it does so thoroughly, including the business constraint on prices. The only mild gap is that the relationship to the takeoff-running tools (must it exist first?) is left implicit.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so every parameter including enums and nested selection/measurements is already documented structurally; baseline 3 applies. The description's only parameter-adjacent remark is that dimensions appear in metric and imperial, which lightly echoes the 'system' parameter without adding syntax or constraints.

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

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

A specific verb-phrase and resource: it produces the one-page job sheet for a takeoff, and enumerates what that sheet contains (SVG picture, dimensions in both unit systems, build-up, buy lines, labour hours, reopening link). That is enough to separate it from siblings like get_takeoff or run_takeoff, but it never names those alternatives, so differentiation is inferential rather than stated.

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

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

Usage is implied by 'the one-page job sheet a takeoff page prints for the van' – an agent can infer this is the printable/field-handout output step after a takeoff exists. There is no explicit when-to-use, no prerequisite stated (does the takeoff need to be run first?), and no alternative tool named.

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

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

Annotations already cover the safety profile (readOnly, idempotent, closed-world, non-destructive), so the bar is lower. The description still adds real behavioral context beyond them: it discloses that the tool will not tell which edition is in force, because adoption is local, and that the answer instead names the deciding authority.

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

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

Two sentences, no filler, with the core function stated first and the limitation second. Every clause carries information and nothing is repeated from the schema or annotations.

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

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

An output schema exists, so return values need not be explained, and annotations cover safety. The description supplies purpose, scope and the key expectation gap (no edition resolution), giving an agent enough to call it correctly; only explicit sibling routing is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

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 all four parameters including the detail enum and the market/subject/calculator formats. The description only loosely maps to 'one kind of work' (subject) and 'one market' without adding syntax or edge-case guidance for detail or calculator, making 3 the correct baseline.

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

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

The description gives a specific verb ('Finds'), an exact resource ('which family of building codes or standards governs one kind of work') and a precise scope ('one market', with the market options enumerated). It is clearly distinguishable from siblings like get_calculator or get_sources, though it never names or contrasts a sibling explicitly.

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

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

Context is implied by the 'one kind of work in one market' scoping and the explicit limitation that it does not resolve the edition in force, but there is no statement of when to prefer this over alternatives such as search, fetch, or get_sources. The caveat 'adoption is local, and the answer names who decides' tells the agent what to expect rather than when to call it.

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

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), so the bar is lower. The description then adds real behavioral context: results come in both metric and US units with an uncertainty band, closure and crossing checks, plus a canvas link, and it flags that no image is ingested.

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

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

A single front-loaded sentence opening with the verb, with no filler. It is dense — parenthetical units, reference types and output features packed into one clause chain — but every element carries information.

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

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

For a 6-parameter nested tool with an output schema, the description supplies the essential mental model: what is measured, what inputs it expects, that a reference is mandatory, and that no image is passed. The remaining gap is routing guidance against sibling measurement tools.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

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 every parameter including the reference object, pixelError, detail and system. The description only restates the conceptual contract (points plus one known reference), adding no syntax or format detail beyond the schema — the baseline 3 applies.

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

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

The description names a precise verb+resource+scope: it measures areas, perimeters and lengths from pixel points plus one known reference, and it explicitly notes it receives no image. That last clause cleanly separates it from image-consuming siblings like run_takeoff or create_project_file_from_plan.

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

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

Usage is only implied: the agent can infer it should call this when it already has point coordinates and a reference scale, and the 'It receives no image' clause rules out image-input workflows. There is no explicit when-to-use, no when-not, and no named alternative among the many measure/takeoff siblings.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false, so safety and side-effect behavior are covered. The description adds that the answer comes in both unit systems and that handing is included by default, which is modest value beyond the structured fields. It does not discuss output format, limits, or how the chart differs behaviorally from a computed result.

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

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

The purpose is front-loaded in a single dense sentence, and each clause maps to a concrete chart section rather than filler. It is somewhat run-on and jargon-heavy, but it is appropriately sized for a chart tool with several output sections.

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

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

With an output schema present, rich annotations, and 100% schema coverage, the description's job is mainly to convey what the chart contains, which it does thoroughly. The one notable gap is routing guidance against close siblings like trim_corner. Otherwise an agent has enough to call the tool correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

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 angles, detail, system, and handing with defaults and enums. The description reinforces the default chart range and mentions handing, but adds no syntax or format detail beyond what the schema provides. Baseline 3 is appropriate when the schema does the heavy lifting.

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

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

The description names a specific resource (the mitre saw chart for trim corners) and enumerates what it contains: mitre per piece, outside-corner reading, gap on 18 mm and 3/4 in trim, crown laid flat, and the handing table. An agent can tell this is a reference/chart tool rather than a single-corner calculator. It does not explicitly distinguish itself from siblings such as trim_corner or calculate, so it falls short of 5.

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

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

Usage is only implied: 'Any corners on request' suggests the angles parameter drives a custom chart, and the tool is clearly for trim mitre reference. There is no explicit statement of when to use this versus trim_corner, calculate, or get_calculator, and no exclusions. This is minimum viable guidance.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered by structured data. The description adds the useful fact that the output is a link embodying the caller's figures and unit system, but does not mention failure behavior (e.g. unknown input ids) or any limits, so it adds modest value over the annotations.

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

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

One sentence, front-loaded with the return value and scoped by the site and the filled-in figures. It is dense but not padded; only the trailing 'so a person can see or change the working' is arguably redundant with the annotation set.

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

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

With an output schema present, the return shape need not be described, and 100% schema coverage handles all six parameters including nested objects. For a read-only link-builder the description covers purpose and audience adequately, though it never explains how this tool relates to the calculate/run_example siblings.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, with detailed per-parameter docs (slug pattern, detail enum, inputs shape, market, system, inputUnits). The description only echoes 'figures filled in and their unit system,' adding nothing the schema does not already say in more detail, so the baseline 3 applies.

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

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

States a specific verb and result ('Returns a link that opens a construction calculator's page on craftquantities.com') plus what the link carries (figures and unit system). It distinguishes itself from siblings like calculate by emphasizing the human-facing artifact ('so a person can see or change the working'), but it never names an alternative tool explicitly.

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

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

The trailing clause implies when to use it — when a person needs to view or edit the working on the page rather than receive a computed answer. There is no explicit when-not guidance and no named alternative (e.g. calculate) for the compute-only case, so the routing guidance is only implied.

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

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

Annotations already declare this a read-only, idempotent, non-destructive, closed-world computation, so the description is free to spend its words on domain behaviour — it discloses the deliverables (stock or sheets to buy, a per-bar/per-sheet cutting plan, real waste, a lower bound) and confines itself to quantities. It does not mention the input caps (200 lines / 3000 pieces) or how defaults are resolved, but those live in the schema.

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

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

Three dense sentences, front-loaded with the verb and the two modes, then the deliverable, then the scope limit. The parenthetical material lists earn their space by making the linear/sheet split concrete, and nothing is repeated.

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

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

For a 14-parameter optimisation engine with full annotation coverage and an output schema, the description supplies what remains needed: what both modes mean, what comes back, and what the tool deliberately does not do. Input limits and defaulting rules are adequately handled by the schema.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% across all 14 parameters, including defaults, unit handling and enum meanings, so the baseline of 3 applies. The description reinforces the semantics of the stock/sheets/pieces inputs in merchant language but adds no format or behaviour detail the schema does not already carry.

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

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

States a specific verb (optimises) and resource (a cut list), then names both operating modes — linear lengths cut from merchant stock versus rectangles nested on sheets — with concrete material examples for each. The closing scoping line ("quantities only: no prices, no structural design") further separates it from pricing or structural siblings such as check_quote or layout_reinforcement.

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

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

Clear context is given for choosing between the two modes, and the description explicitly excludes pricing and structural design, which is a genuine scope boundary. It never names an alternative sibling (fit_panel, layout_reinforcement, miter_chart) or says when to reach for those instead, leaving that routing to the agent.

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

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

Annotations already declare readOnly/idempotent/non-destructive, so the safety profile is covered; the description adds real value beyond that by disclosing the returned deliverables (totals, CSV, an iCalendar file only when a start date is given) and the explicit modelling exclusions. It does not discuss failure modes or error handling, so it falls just short of the top band.

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

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

Front-loaded with purpose, then output, inputs and exclusions in a compact block with essentially no filler. It is dense, jargon-heavy and slightly run-on (multiple clauses stacked per sentence), which mildly reduces scannability but does not cost useful content.

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

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

For a 14-parameter tool with nested objects and zero required inputs, the description covers the purpose, accepted input sources, deliverables and modelling boundaries, and an output schema exists so return values need not be re-explained. Missing only explicit guidance on choosing among the competing input sources (token vs file vs takeoffs vs drawing).

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so all 14 parameters (including nested drawing/takeoffs shapes) carry their own documentation and the baseline is 3. The description adds only soft framing (hours distributed "over the crew and working day given") rather than syntax or defaults not already in the schema.

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

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

A specific verb ("Builds") plus a precise resource ("a construction programme … from a project's labour hours"), with the produced artifact spelled out (tasks by trade, stage and level, ordered by the usual sequence of work). An agent can distinguish it from plan_project, plan_room and the create_project_file_* siblings without opening a schema.

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

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

It names the accepted input sources ("a project state token, a My Project file, takeoffs or a drawing") and states scope limits ("Weather, inspections and lead times are not modelled. No prices."), which indicates when the tool applies. It stops short of explicitly routing the agent against a named sibling or stating when-not to use it.

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

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

Annotations already cover the safety profile (readOnlyHint, idempotentHint, destructiveHint=false, openWorldHint=false), so the description only needs to add what they don't. It does: it enumerates the returned artifacts (each space's rows, every line together, labour hours, the plan) and, more usefully, states a hard boundary — "Quantities only; it does not size structure" — which tells an agent what the tool will not do.

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

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

Two compact sentences that front-load the verb and resource before the output and boundary clauses. Dense phrasing ("each space's rows, every line together") is slightly opaque but no sentence is wasted.

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

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

An output schema exists, so return values need not be spelled out, and 80% of parameters are covered by the schema. The description supplies the purpose and the quantities-only boundary appropriate to a complex nested-input tool. The main residual gap is the relationship to plan_room and whether anything is persisted, though readOnlyHint answers the latter.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 80%, so parameters such as detail, system, inputUnits and the roof sub-fields are already documented in the schema. The description only adds that the roof is optional, which is already implied by the schema's non-required roof property. Baseline 3 applies when the schema carries the parameter burden.

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

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

States a specific verb ("Plans"), the resource (several spaces tied together as one project in the room planner), and the scope of what it produces (rows, lines, labour hours, the plan). The plural "several spaces together" implicitly distinguishes it from the singular plan_room sibling, but it never names that sibling, so the differentiation is left to inference.

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

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

The phrase "Plans several spaces together ... as one project" implies the multi-space use case versus single-space planning, and "with an optional roof over them" hints at when the roof block applies. However, there is no explicit when-to-use, when-not-to-use, or routing to alternatives such as plan_room, so usage must be inferred.

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

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

Annotations already declare readOnly, idempotent, non-destructive and non-open-world, so the safety profile is covered. The description adds value beyond that by spelling out the return contents and asserting a hard scope boundary: 'Quantities only; it does not size structure,' which tells the agent what this tool will not produce.

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

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

Two sentences, front-loaded with the core action and immediately followed by the output contract and the scope caveat. No filler and every clause carries information.

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

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

An output schema exists, so return values need no further elaboration, and annotations cover the safety profile. The description supplies the scope limit and output summary; only fine-grained guidance on the 13 parameters is thin, and the schema largely covers that.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 77% and 13 parameters are documented in the schema itself. The description only gestures at the input dimensions ('its size, openings and the finishes chosen'), loosely mapping to figures, doors/windows and finishes, without adding format, unit or id-semantics detail beyond the schema. Baseline 3 is appropriate.

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

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

States a specific verb (Plans) and resource (one space such as a room or bathroom) and describes the output shape in detail (materials list rows with quantity, remaining needs, unbuilt items and reasons, and labour hours). The scope is narrow enough to separate it from the project-level sibling plan_project without opening either schema.

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

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

The 'one space' framing implies when to use it versus a whole-project planner, but no alternative is named and there are no explicit when/when-not conditions or prerequisites. Usage is inferable but not stated.

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

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

Annotations already establish read-only, idempotent, non-destructive, closed-world behavior. The description adds substantial behavioral detail beyond that: fitting order, long and short point lengths, end treatments with saw settings, cut list, and trim lengths to buy.

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

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

It is a single front-loaded sentence, with the colon cleanly separating purpose from output details. It is dense but has little filler; splitting it could improve readability, but it is appropriately sized for a 21-parameter planning tool.

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

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

With an output schema, rich annotations, and 95% schema description coverage, the description is complete at the high level an agent needs. It covers the main input modes and outputs, though it does not explicitly state the walls-plus-corners versus drawing input choice or defaults, which the schema handles.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 95%, so the schema already carries nearly all parameter meaning. The description adds only high-level input modes such as corners, openings, built-ins, and drawn rooms, without adding defaults, unit behavior, or syntax beyond the schema.

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

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

States a specific verb and resource: plans trim round a room piece by piece from corners, openings, built-ins, or a drawing. The scope and output list distinguish it from a single-corner tool or saw chart, even though it does not name siblings explicitly.

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

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

The description gives a clear planning context, especially for whole-room trim from walls or a drawn room. However, it never says when to choose this over trim_corner, miter_chart, optimise_cuts, or plan_room, so usage is implied rather than explicit.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false, covering the safety profile. The description adds that the output includes lines as SVG and DXF, checks and omissions, and paper tiling behaviour, which is useful beyond annotations, but it does not describe error behavior, performance, or how the template is generated.

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

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

The description is a single front-loaded sentence that immediately identifies the resource. It is somewhat list-heavy and repeats template types that also appear in the calculator and kind schema descriptions, but it remains appropriately sized and does not contain wasted framing.

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

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

Given an output schema and rich annotations, the description does not need to explain return values or safety properties. It sufficiently covers scope, output formats, checks/omissions, and paper tiling for a 12-parameter read-only generation tool, though it could be more complete on when to choose it over related drawing tools.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 92%, so most parameter semantics are already documented in the schema. The description adds little parameter-level detail beyond mentioning SVG/DXF lines and tiling on paper, so the baseline of 3 is appropriate.

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

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

The description states a specific resource — the full-size printable template produced from a calculator page — and lists example template families (stair stringer, rafter cuts, cone pattern, arch centring, anchor bolt jig, curved plate). It does not explicitly distinguish itself from sibling drawing tools such as create_drawing or export_drawing, so sibling differentiation is absent.

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

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

Usage is implied by 'the full-size template a calculator page prints', suggesting it is used after or alongside calculator results. However, there is no explicit when-to-use guidance, no when-not-to-use guidance, and no named alternatives among the many drawing/template siblings.

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

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

Annotations already declare readOnly, idempotent, non-destructive, and closed-world, so the safety profile is covered. The description adds genuinely new behavior: ids are assigned once and survive renames/moves, and a removed page names its replacement. It stops short of stating failure behavior for an unresolvable or ambiguous ref.

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

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

Two sentences, front-loaded with the action and its accepted inputs, followed by the persistence and replacement semantics. No filler, no restatement of the title.

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

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

An output schema exists, so return values need not be detailed, yet the description still previews them. For a three-parameter, fully-documented, read-only lookup with a closed-world annotation, nothing an agent needs in order to call it correctly is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so all three parameters are already documented in the schema, including the ref formats and the summary/full detail tradeoff. The description largely restates those accepted ref forms rather than adding syntax, precedence, or ambiguity-handling rules. Baseline 3 applies when the schema does the heavy lifting.

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

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

The description names a specific verb (resolves) and a specific resource (a Craft Quantities page identified by permanent id, slug, or address), then enumerates what comes back: kind, current slug, slug history, page link, permanent /id/ link. This is clearly distinguishable from siblings like fetch, search, get_calculator, and open_in_site_link.

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

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

Acceptable input forms are spelled out (permanent id such as cq-c0412, current or earlier slug, or a craftquantities.com address), which implies when the tool applies. However, it never names an alternative or states when not to use it — e.g., when search or fetch would be the better route for a bare query.

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