OpenTakeoff: a takeoff engine that agents and estimators share

Two front ends on one measurement engine

OpenTakeoff describes itself as a takeoff tool, and a takeoff is the act of measuring quantities off a construction drawing. The README's framing is that the engine is built so an AI agent can drive it and so an estimator wants to, with the same engine underneath both.

The two front ends are a set of 53 MCP tools for an agent and a browser canvas for a person. The README is explicit that agents and people share the takeoff document and the quantity calculations, which is the design decision that matters. This is not an agent tool that exports measurements for a person to re-enter somewhere else.

The mechanics of a measurement are described with unusual precision. Each sheet carries its own calibration, measurements carry geometry, method and authorship, recalibration updates quantities together, incompatible imports report scale conflicts, and agent measurements carry an explicit review status. That last point is the one to sit with: a measurement made by an agent is marked as such and marked as pending review, rather than being indistinguishable from a human's.

The audience is preconstruction. The README calls the tool the measurement engine for building plans, and points at estimators with a bid due, at developers building on the engine, at agents, and at crews who want their own instance. The repository layout matches that split between product and platform: `web/` holds the canvas, `mcp/` the tool server, `protocol/` the protocol work, `evals/` the evaluation harness, and `demo/` a sample plan generator with a sample finish plan PDF.

The MCP server is the product an agent actually sees

For an agent, the entry point is a single command. The README points at `npx -y opentakeoff-mcp` and then the agent manual, which is described as covering the operating model, the standard finish every takeoff ends with, what the engine refuses to guess, and why. The tool-by-tool reference sits in mcp/README.md.

The point of the agent manual's structure is that a measurement is not a freeform action. There is a standard finish, a documented set of refusals, and a set of tools that cover measurement, sweeps and derivation. That is a much better contract for an automated caller than a bag of primitives.

The package is published on npm as opentakeoff-mcp and is listed in the Model Context Protocol registry. The release tags follow a pattern of their own, with mcp-v0.9.98 dated 2026-10-11 and mcp-v0.9.96 dated 2026-10-03, so the MCP server versions independently of the application.

The server also runs as a container, and the root Dockerfile exists so that registry build systems find a working build without guessing a context. The build is a two stage build on node:24-bookworm-slim, and the runtime stage drops to the `node` user before running the stdio entry point:

#   docker build -t opentakeoff-mcp .
#   docker run --rm -i opentakeoff-mcp        # -i: MCP speaks JSON-RPC over stdio

The `-i` flag matters. The server speaks JSON-RPC over stdio, so it is an interactive process rather than a daemon you curl, and a build system that runs it without a pipe will see it exit immediately.

One-Click is gated, so know what is missing

The README leads with a warning that any evaluation of this tool has to account for: One-Click Area is temporarily gated. The flood engine behind it is being re-validated against a wider plan corpus, and until that finishes the One-Click tool is off the canvas rail, with the `O` key reporting the gate. Over MCP, the `one_click` and `detect_rooms` verbs are not registered.

A default build ships 53 tools. The workaround is documented: trace rooms with Area, the `A` key on the canvas, and `measure_polygon` over MCP. Every other tool, sweep and derivation is unchanged. The gate can be lifted with `VITE_ONE_CLICK=1` for the canvas or `OPENTAKEOFF_ONE_CLICK=1` for the server.

That last point carries an implicit warning. The gate exists because the flood engine is being re-validated, and the README says sections and videos that show One-Click describe the engine as it returns rather than as it currently ships. So a feature that reads as automatic room detection in the marketing copy is, in the default build, something the operator drives by hand.

For an agent integrator this is concrete and checkable. Count the tools in the build you actually installed rather than trusting a number in a README, and treat the missing verbs as a design constraint on your workflow, not as a temporary inconvenience. The design rationale is written up in docs/design/ONE_CLICK_GATE.md.

Client-only in the browser, with the memory limits that implies

OpenTakeoff is a client-only browser app. The canvas runs the same on Windows, macOS, ChromeOS and Linux in any current Chrome, Edge, Firefox or Safari, nothing installs, nothing uploads, and no feature is gated on an operating system. For an estimator that is the whole pitch: drag in a plan, no account, and the file never leaves the machine.

That constraint drives the rest of the design, and the README is refreshingly specific about it. Sheet navigation releases closed PDFs and embedded fonts from the tile workers, which is checked by a 30-flip rendering check. Beyond the PDFs in open tabs, at most four idle PDFs stay loaded, two on a phone or tablet or on a browser reporting 4 GB of memory or less, with least recently used evicted first, verified by a 12-PDF check.

So the engine is doing its own memory management for large plan sets, and it does it in the browser tab rather than in a service. That is a real constraint for anyone planning to use it on a very large bid set on a laptop, and the numbers to test against are published in the review documents under docs/review/.

Two optional extras sit outside the canvas. The bundled capture server is stdlib Python 3 and runs anywhere Python does, invoked on Windows with `python capture\capture_server.py selftest` rather than `python3`. Neither it nor the optional server/ AI sandbox is needed to use the canvas, which is worth knowing if you were planning a deployment and assumed a backend was involved.

Provenance in the document rather than in a spreadsheet

The README describes the data layer as the reason the engine exists, and it lists the properties that make a takeoff auditable.

Scale and origin are per sheet. A drawing set with more than one scale, or sheets with different origins, is where takeoff tools usually lose trust, so the engine attaches the calibration to the sheet rather than to the document, and recalibration propagates through the quantities rather than leaving stale numbers behind. Imports that cannot be reconciled report scale conflicts instead of silently guessing.

Authorship is recorded per measurement, and method and geometry travel with it. On top of that, agent measurements carry an explicit review status, so a quantity derived by a model is distinguishable from one a person measured and accepted. For preconstruction work, where the numbers go into a bid that carries contractual weight, that distinction is the difference between a tool you can sign off and one you cannot.

The product lines and quantities are described as carrying full provenance, and the README points at a standard finish that every takeoff ends with, which is the engine's way of describing a repeatable closure state rather than an ad hoc set of loose measurements.

The measurement model itself is stated in the description: rooms are measured on the wall faces, symbol sweeps handle repeated items, and product lines plus quantities are produced with full provenance, built for preconstruction.

AGPL-3.0, protocol work, and a fork-first deployment story

OpenTakeoff is released under AGPL-3.0, and the README's fork section is explicit that a crew wanting its own copy gets its own instance on its own URL, with nothing phoning home, and that the same path applies if you are going to send a pull request.

AGPL-3.0 is the licence to think carefully about here. It is the strongest of the common open source licences for network use, because the copyleft reaches users interacting with the software over a network, not only those who receive the source. Running a modified OpenTakeoff as a service for a crew means the source of your modifications has to be offered to those users. For internal use inside one organisation that is mostly a non-question. For a hosted product built on the engine, it is a legal question that has to be answered before, not after, the first deployment.

The repository reflects the obligations, with a LICENSE file, a NOTICE file, a THIRD-PARTY-NOTICES.md, and a LICENSES/ directory.

On protocol work, the README points at a Takeoff Protocol draft and compatibility status document, with the note that it is formalizing existing records and that current takeoff behavior is unchanged. That is the right way to introduce a protocol: describe what already happens, then name it.

For developers, AGENTS.md is described as the repo map and the ship discipline, and FEATURES.md maps every capability to the code that implements it. The documentation is unusually layered: a user manual with a working order for a real bid, an agent manual, a Phase 1 test guide, plus translations into Japanese, Korean and Simplified Chinese.

The release cadence is visible and fast. Tags such as mcp-v0.9.98 on 2026-10-11 and mcp-v0.9.94 on 2026-10-01 show regular MCP server releases, the repository is not archived, and the last push was on 2026-10-19.

Where OpenTakeoff is the wrong choice

The clearest wrong-tool case is automatic room detection. If your workflow depends on the engine finding rooms for you, the default build does not do that today, and the documented alternative is manual polygon measurement over MCP or the Area tool in the canvas. The work does not disappear, it moves to whoever is driving, and in an agent pipeline that means writing the room logic yourself on top of `measure_polygon`.

The second limit is the deployment model. Locked-down enterprise fleets, with MSIX packaging, Windows Sandbox and Intune silent deploy, are tracked in issue #226 and not yet built. A team that has to hand the tool to contractors on managed Windows devices will hit that gap, and it is an explicit gap rather than a missing feature nobody noticed.

The third limit is scale on modest hardware. The memory policy is designed around a browser tab holding a handful of PDFs and evicting the rest. Very large bid sets on a laptop are where that design is stressed, and the published checks give you the numbers to reason about it before you commit.

The fourth is the licence, and it deserves a mention in this list rather than only in the previous section. AGPL-3.0 plus a protocol that is still a draft means the contract between your code and the engine is not fully settled. An organisation that wants to own a modified engine and keep it internal can do that; an organisation that wants to ship a hosted takeoff product on top of it has a decision to make about licence compliance and about a protocol that is still being formalized.

The alternative to all of this is the commercial takeoff software an estimator already has, which arrives with vendor support, established importers for real plan sets, and no licence conversation. The difference in approach is that OpenTakeoff gives you the measurement engine as inspectable source with an agent-facing contract, and a fork you can host yourself, at the cost of doing the parts that are still gaps, such as room detection, yourself.

Editorial conclusion

Adopt OpenTakeoff when you need quantity takeoff on construction plans and you want the same engine to be drivable by an agent and by a person, since the shared document, per-sheet calibration and explicit review status on agent measurements are the parts that make agent output auditable. Do not adopt it if you need automatic room detection, because the One-Click tool is temporarily gated and the one_click and detect_rooms MCP verbs are not registered in a default build, and do not adopt it for locked-down enterprise deployment, which is tracked in issue #226 and not yet built. Before you build on it, read the agent manual and the Phase 1 test guide, check the tool count in the build you install, and set the scale and origin of every sheet yourself rather than relying on the engine to infer it.

Frequently asked questions

Official sources

1. Kentucky-ai/opentakeoff on GitHub
2. License: AGPL-3.0
3. Project website
4. README
5. Releases