opentakeoff-mcp

Overview Schema Source Related Servers Discussions Admin

estimate_summary

Retrieve a read-only priced estimate summary showing line-item quantities, rates, material and labor costs, overhead, profit, base bid, pricing status, and every missing or unpriced item.

Instructions

The priced estimate — the canvas Estimate panel as data: one line per quantity kind each measured condition carries — its area, LF and EA are separate lines (unit, order and measured quantities, rates, material / labor / supply cost, main marks each condition's first line; status priced | partial | unpriced with what is missing, or optional — a bordered linear run's derived line nobody priced, carried in its main line and never missing; set_pricing prices any line: the main one by default, the others with line "LF" / "EA" / "SF"), then material, labor, sales tax, cost, overhead, profit and the base bid. complete is false while anything is unentered: the total then counts the missing pieces at $0 and is "priced so far", and unpriced lists every hole — report it to the estimator, never fill it. Read-only.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "estimate_summary"
  }
}

Input Schema

Name	Required	Description	Default
No arguments

Output Schema

Name	Required	Description
`tax`	Yes	Sales tax on material
`cost`	Yes	material + labor + tax
`note`	Yes
`labor`	Yes
`lines`	Yes
`total`	Yes	The base bid — 'priced so far' while complete is false
`profit`	Yes
`complete`	Yes
`material`	Yes	Condition material + supply rows
`overhead`	Yes
`settings`	Yes
`unpriced`	Yes
`warnings`	Yes
`settings_source`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed10 schema fields changedv0.1.31Nov 7, 2026

changedOutput schema / properties / lines / items / additionalProperties
```
Previous value: -trueNew value: +{}
```

addedOutput schema / properties / lines / items / properties / key

Added value: +{
+  "description": "\"<condition id>:<unit>\" — one line per quantity kind the condition carries",
+  "type": "string"
+}

addedOutput schema / properties / lines / items / properties / main

Added value: +{
+  "description": "The condition's first line: priced by pricing.unit / material / labor and carrying its assembly items; the others price from pricing.by_unit[unit]",
+  "type": "boolean"
+}

changedOutput schema / properties / lines / items / properties / materials / items / additionalProperties
```
Previous value: -trueNew value: +{}
```

addedOutput schema / properties / lines / items / properties / optional

Added value: +{
+  "description": "A bordered linear run's derived line: priceable, but an empty rate is carried in the main line, never missing",
+  "type": "boolean"
+}

addedOutput schema / properties / lines / items / properties / status / description
```
Added value: +"optional = an optional line nobody priced (not in unpriced)"
```

changedOutput schema / properties / lines / items / properties / status / enum

Previous value: -[
-  "priced",
-  "partial",
-  "unpriced"
-]New value: +[
+  "priced",
+  "partial",
+  "unpriced",
+  "optional"
+]

changedOutput schema / properties / settings / additionalProperties
```
Previous value: -trueNew value: +{}
```
changedOutput schema / properties / unpriced / items / additionalProperties
```
Previous value: -trueNew value: +{}
```

addedOutput schema / properties / unpriced / items / properties / unit

Added value: +{
+  "description": "Which of the condition's lines is unpriced",
+  "enum": [
+    "SF",
+    "SY",
+    "LF",
+    "EA"
+  ],
+  "type": "string"
+}

Addedv0.1.29Oct 25, 2026

TDQS

A3.7/5.0

Behavior4/5

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

With no annotations supplied, the description carries the full burden and does substantial work: it declares read-only behavior, defines the complete flag semantics (false while anything is unentered), explains that missing pieces count at $0 so the total is 'priced so far', and enumerates status values priced | partial | unpriced | optional. It stops short of describing error conditions or permission requirements, but for a zero-argument read this is well above the norm.

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

Conciseness3/5

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

The core ('the priced estimate ... as data') is front-loaded, but the body is a single sprawling sentence threaded with em-dashes and parentheticals that is hard to parse on first read. A large fraction of the text is a set_pricing tangent (line selectors LF/EA/SF) that belongs in the sibling's description, even if it usefully warns the agent off trying to price here.

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

Completeness4/5

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

For a parameterless read tool with an output schema and no annotations, the description covers the important semantics: line decomposition by quantity kind, pricing status, and the complete/unpriced contract. Some of the return-value detail is redundant against the output schema, and nothing addresses failure modes, but an agent has enough to call it and interpret the result correctly.

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

Parameters4/5

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 is 4. The only 'line' argument discussed belongs to set_pricing, not to this tool.

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

Purpose4/5

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

The opening clause ('The priced estimate — the canvas Estimate panel as data') and the closing 'Read-only.' make clear this retrieves the priced estimate structure rather than mutating anything. It is not verb-first and never names the sibling it is distinguished from (takeoff_summary, export_estimate), but an agent can still infer the resource from the enumerated contents.

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

Usage Guidelines3/5

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

It routes mutation intent away from this tool explicitly ('set_pricing prices any line: the main one by default, the others with line "LF" / "EA" / "SF"') and tells the agent what to do with holes ('report it to the estimator, never fill it'). What it never states is when to reach for this tool rather than takeoff_summary or export_estimate, so selection guidance against siblings is only implied.

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

Deploy Server