Auditable construction takeoffs with locked waste and conservative purchase rounding.
Scored across 7 tools
Most tools have clearly distinct purposes: calculate, verify, list/get assemblies, and list/get material packs are discernible. However, list_material_pack and get_material_pack overlap substantially in content (both return digest, coverage, and pack metadata), and describe_agent is a meta-capability tool that could be confused with pack/assembly listing if an agent is skimming.
All tool names follow a consistent snake_case verb_noun pattern: calculate_takeoff, describe_agent, get_assembly, get_material_pack, list_assemblies, list_material_pack, verify_result. The verb choices (get/list/calculate/verify) are used predictably.
Seven tools is a reasonable, well-scoped set for a takeoff service. There is minor duplication between the list/get pairs for assemblies and material packs, and describe_agent is a peripheral metadata tool, but no tool feels extraneous.
The surface covers the core lifecycle: calculation, audit verification, assembly discovery, material-pack inspection, and agent capability description. Gaps remain around custom material/assembly creation, batch takeoffs, or export operations, but agents can work around these for the stated planning-estimate purpose.
Calculate an auditable material takeoff from explicit geometry or a supported SmartScale/ProtoGen measurement payload. Returns net, explicit waste-adjusted, and conservative purchase quantities. This is a planning estimate, not a guaranteed material order or professional certification.
| Name | Required | Description | Default |
|---|---|---|---|
| items | Yes | ||
| options | No | ||
| request_id | No | ||
| payment_ref | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish that this is a read-only, idempotent, non-destructive operation. The description adds useful behavioral context beyond annotations by stating that it returns net, waste-adjusted, and conservative purchase quantities and by clarifying that the result is a planning estimate rather than a guaranteed order or certification.
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 three tightly written sentences with no wasted text. Purpose is front-loaded, followed by return values and an important caveat.
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-value structure need not be explained, and annotations cover the safety profile. However, given the completely undocumented input schema, especially the untyped items array and options object, the description is not complete enough to tell an agent exactly how to construct a valid call.
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 0%, so the description must carry the burden of explaining four parameters, including a complex items array and an opaque options object. It partially compensates by naming explicit geometry and SmartScale/ProtoGen payloads as input sources, but it does not explain the structure of items, options, request_id, or payment_ref.
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: "Calculate an auditable material takeoff." It also names the accepted input modes (explicit geometry or SmartScale/ProtoGen payload), which clearly separates this computation tool from retrieval-oriented siblings such as get_material_pack and list_assemblies.
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 states the input contexts in which the tool applies, but it does not explicitly say when to use this versus alternatives or when not to use it. The caveat that it is a planning estimate implies boundaries, but routing guidance is only implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return fleet-standard capabilities, version, pack digest, disclaimer, composition role, and pricing.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
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 fully covered and the description adds no contradictory claims. It contributes nothing beyond that, though — no note on whether the response is stable across calls, whether pricing is static, or whose manifest is being described.
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 compact sentence enumerating the return payload with no filler or redundancy, and the most important items (capabilities, version) are front-loaded. It is well-sized for a trivial no-argument tool, though the comma-spliced wrap adds nothing structural.
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 description partially duplicates it, so return values need no further explanation. However, the one thing an agent genuinely cannot infer — which agent is being described, given there is no identifier parameter — is left unaddressed, which is the main completeness 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?
The tool takes zero parameters, so per the baseline this scores 4. The field list in the description is unrelated to argument semantics and adds no parameter meaning, but none is required.
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?
Uses a specific verb ('Return') and enumerates the exact fields returned (capabilities, version, pack digest, disclaimer, composition role, pricing), so the agent knows this is a metadata/introspection call. It falls short of a 5 because 'fleet-standard' and 'composition role' are unexplained jargon, and with zero parameters it never clarifies whether it describes the calling agent or an external 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 statement of when to call this versus the sibling tools (get_assembly, get_material_pack, verify_result, list_*), nor any prerequisites or exclusions. Only an indirect implication that it is useful when the agent needs self/metadata facts, which the reader must infer entirely.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return one assembly's formula, required dimensions, material factors, purchase increment, sources, and material-pack lineage.
| Name | Required | Description | Default |
|---|---|---|---|
| assembly_type | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
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. The description adds the retrieval scope but says nothing about lookup failure behavior or whether values are computed or stored; with annotations doing heavy lifting, a 3 is right.
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 no filler; every listed field conveys real scope 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?
The output schema exists, so return-value explanation is not strictly needed, and annotations cover safety. The remaining gap is how to obtain a valid assembly_type and what happens on a miss, which the description leaves entirely unaddressed for an otherwise simple one-parameter tool.
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 0% for the single parameter 'assembly_type', and the description does not compensate: no format, allowed values, or pointer to list_assemblies as the source of valid identifiers. The agent must guess what string to pass.
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 ('Return') and a precise resource ('one assembly') and enumerates the returned facets (formula, dimensions, material factors, purchase increment, sources, material-pack lineage). This clearly separates it from list_assemblies, though the sibling is never named and 'assembly_type' is left undefined as a concept.
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 prerequisite guidance. The singular 'one assembly' only weakly hints that it complements list_assemblies, and nothing tells the agent what to do when the requested assembly does not exist.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return the bundled factors, densities, coverages, waste defaults, purchase increments, unit conversions, sources, and raw-pack SHA.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, idempotent, closed-world, non-destructive, so the safety profile is fully covered. The description adds that the pack is a static bundle including a 'raw-pack SHA', hinting at versioned/reference data, but does not state cost, caching, or that the result is static across 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?
A single front-loaded sentence with the verb first and the returned payload enumerated; nothing extraneous, though the field list is long it maps directly to 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 present, return-value detail need not be repeated, and annotations cover safety. The only remaining gap is the lack of routing guidance among siblings, which the description does not supply.
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?
The tool takes zero parameters, so the baseline is 4; the description correctly implies a no-argument fetch and doesn't mislead about inputs.
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 ('Return the bundled...') and enumerates the contents of the material pack, which makes the purpose concrete. It does not distinguish itself from the sibling list_material_pack, whose name suggests overlapping subject matter, so differentiation is left implicit.
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 indication of when to call this versus list_material_pack or get_assembly, and no mention of prerequisites or typical workflow position (e.g., call before calculate_takeoff). The agent must infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List supported assemblies, required dimensions, formulas, waste defaults, and the current material-pack digest.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
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 the useful detail that results include formulas, waste defaults, and a material-pack digest, but says nothing about caching/refresh semantics of the digest.
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 delivering the verb first and the payload contents second, with 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 a rich output schema covering return values and annotations covering safety, the description needs only to frame the scope, which it does. The missing piece is routing guidance versus get_assembly/list_material_pack.
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?
The tool takes no parameters, so there is nothing for the description to disambiguate; baseline 4 applies. The description correctly implies an unfiltered enumeration of all assemblies.
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 ('List supported assemblies') with an enumeration of the payload contents (dimensions, formulas, waste defaults, material-pack digest). It does not, however, distinguish itself from siblings like get_assembly or list_material_pack, whose scope overlaps.
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 statement of when to call this instead of get_assembly (single assembly detail) or list_material_pack, nor any precondition or exclusion. The agent must infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the bundled material pack version, digest, coverage, shapes, rebar sizes, roof pitches, and explicit unsupported policy.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
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 structurally. The description adds one genuinely new behavioral fact — that an explicit unsupported policy is included, signalling what the pack does NOT cover — but says nothing about cost, size, or stability of the returned metadata.
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 no filler, though the middle section is a flat comma list of fields that partially repeats what the output schema already declares.
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 shape needn't be explained, and the annotations fully cover the safety profile. For a zero-parameter read-only metadata tool, 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?
Zero parameters, so there is no parameter semantics to explain; the schema is empty and complete. Baseline 4 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 (List) and resource (bundled material pack) and enumerates exactly which facets are reported: version, digest, coverage, shapes, rebar sizes, roof pitches, unsupported policy. This lets an agent distinguish it from content-returning siblings like get_material_pack, though the differentiation is implicit 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 description gives no when-to-use condition, no prerequisites, and never names an alternative such as get_material_pack or list_assemblies. An agent must infer that this is a metadata/discovery call from the enumerated fields alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recompute a takeoff audit hash, notary payload, pack currency, and QT9 unit-resolved conservation. Pass the prior result object as JSON.
| Name | Required | Description | Default |
|---|---|---|---|
| result_json | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
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 covered. The description adds that the tool recomputes several audit artifacts, but does not disclose failure behavior, error handling, or the relationship to calculate_takeoff output beyond the 'prior result' hint.
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 recomputation targets and ending with the input instruction. Every sentence earns its place with 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, and annotations cover the safety profile. The description is nearly complete for a one-parameter verification tool, though it could more explicitly tie the 'prior result' to calculate_takeoff output.
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 0%, so the description carries the burden of explaining the sole parameter. It identifies result_json as the prior result object serialized as JSON, which is helpful, but does not specify the expected shape, where to obtain it, or serialization details.
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 specific recomputation targets (takeoff audit hash, notary payload, pack currency, QT9 conservation), which clearly distinguishes this as a verification tool rather than a calculation or listing tool. It does not explicitly name or route against siblings, but the scope is specific enough for an agent to identify the operation.
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 'Pass the prior result object as JSON' implies the tool is used after a prior result exists, likely from calculate_takeoff. However, it does not explicitly state when to use this versus calculate_takeoff or what to do if no prior result is available.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
calculate_takeoff1 field changedInput schema / properties / request_idAdded value: +{
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Request Id"
+}calculate_takeoff1 field changedInput schema / properties / payment_refAdded value: +{
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Payment Ref"
+}calculate_takeoffdescribe_agentget_assemblyget_material_packlist_assemblieslist_material_packverify_resultAI takeoff for construction: turn PDF blueprints into structured, traceable quantities.
Construction quantities from cited calculators, takeoffs, planners, drawings, cut plans. No prices.
Construction takeoff and estimating for AI agents. Measure a drawing PDF, export a priced estimate.
AI-native operating system for general contractors: estimates, takeoff, bids, pay apps.
Add one secure layer between your agents and this server.
