opentakeoff-mcp

Overview Schema Source Related Servers Discussions Admin

export_marked_pdf

Writes a distribution-ready PDF of marked-up plans with legend, quantities, and annotations, providing evidence for construction takeoffs. Outputs to disk with default path next to the source plan.

Instructions

The MARKED-UP PLANSET — the deliverable of every takeoff. Writes a distribution-ready PDF to disk: a legend cover (per-condition totals, swatches, a by-sheet breakdown) followed by every sheet that carries takeoff shapes or annotations, vector-copied from the source plan with the work burned in as drawn — condition colors and hatches, a quantity chip on every shape, annotation clouds/callouts/highlights, and approval marks (the estimator's APPROVED rings, the agent's AGENT diamonds — the cover tallies the split). Built by the same module as the canvas's MARKED SET button, so agent output and app output are one implementation. A construction takeoff is no good without markup: finish EVERY takeoff by writing this file and giving the user its path (export_report carries the numbers for pricing; this carries the evidence). When the shapes were machine-traced and unreviewed, the document says so on its last page — the review path is importing the export_takeoff payload into the app, where agent shapes arrive as pencil proposals. Default path: next to the loaded plan as " - marked set.pdf". Needs no native canvas — pure vector copy, so it works even where view_sheet cannot render. The one source it refuses: an ENCRYPTED plan PDF (owner password, empty user password — it opens everywhere, but its pages cannot be vector-copied and there is no canvas here to render them); the refusal names the sheet — export the marked set from the app, or supply an unencrypted PDF.

Input Schema

TableJSON Schema

Name	Required	Description
`path`	No	Where to write the PDF (default: "<plan dir>/<plan> - marked set.pdf")
`overwrite`	No	Replace the file at path even when it is not an OpenTakeoff export. Off by default: re-exporting over a previous export of your own already overwrites without this, so you only need it to deliberately destroy an unrelated file.
`project_name`	No	Cover-page project name (default: the plan file's name)

Output Schema

TableJSON Schema

Name	Required	Description
`note`	Yes
`path`	Yes	Absolute path of the written marked-set PDF — hand this to the user
`pages`	Yes	Legend cover + the RFI schedule page(s) when any RFI is live + one page per marked sheet
`rfis_printed`	Yes	Live RFIs printed on the RFI schedule page (#364) — agent-raised and panel-raised alike; withdrawn ones leave a numbering gap
`shapes_drawn`	Yes
`sheets_marked`	Yes	Sheets carrying shapes, annotations, or approval marks — unmarked sheets are omitted
`approvals_drawn`	Yes	Approval-family glyphs burned in (#176) — estimator APPROVED rings + agent AGENT diamonds; the cover tallies the split when any exist
`annotations_drawn`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedv0.1.21Sep 12, 2026

changedOutput schema / properties / pages / description

Previous value: -"Legend cover + one page per marked sheet"New value: +"Legend cover + the RFI schedule page(s) when any RFI is live + one page per marked sheet"

addedOutput schema / properties / rfis_printed

Added value: +{
+  "description": "Live RFIs printed on the RFI schedule page (#364) — agent-raised and panel-raised alike; withdrawn ones leave a numbering gap",
+  "type": "integer"
+}

changedOutput schema / required

Previous value: -[
-  "path",
-  "pages",
-  "sheets_marked",
-  "shapes_drawn",
-  "annotations_drawn",
-  "approvals_drawn",
-  "note"
-]New value: +[
+  "path",
+  "pages",
+  "sheets_marked",
+  "shapes_drawn",
+  "annotations_drawn",
+  "approvals_drawn",
+  "rfis_printed",
+  "note"
+]

Changed1 schema field changedv0.1.15Aug 6, 2026

addedInput schema / properties / overwrite

Added value: +{
+  "description": "Replace the file at path even when it is not an OpenTakeoff export. Off by default: re-exporting over a previous export of your own already overwrites without this, so you only need it to deliberately destroy an unrelated file.",
+  "type": "boolean"
+}

Changed3 schema fields changedv0.1.12Aug 3, 2026

addedOutput schema / properties / approvals_drawn

Added value: +{
+  "description": "Approval-family glyphs burned in (#176) — estimator APPROVED rings + agent AGENT diamonds; the cover tallies the split when any exist",
+  "type": "integer"
+}

changedOutput schema / properties / sheets_marked / description

Previous value: -"Sheets carrying shapes or annotations — unmarked sheets are omitted"New value: +"Sheets carrying shapes, annotations, or approval marks — unmarked sheets are omitted"

changedOutput schema / required

Previous value: -[
-  "path",
-  "pages",
-  "sheets_marked",
-  "shapes_drawn",
-  "annotations_drawn",
-  "note"
-]New value: +[
+  "path",
+  "pages",
+  "sheets_marked",
+  "shapes_drawn",
+  "annotations_drawn",
+  "approvals_drawn",
+  "note"
+]

Addedv0.1.9Jul 31, 2026

TDQS

A4.6/5.0

Behavior5/5

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

With no annotations, the description carries the full burden and does so: it discloses the output structure, that unreviewed shapes are flagged on the last page, the default output path, that it needs no native canvas, and a specific refusal case (encrypted owner-password PDFs) with the reason and remedies. This is far beyond what structured fields provide.

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

Conciseness4/5

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

Front-loaded with the core deliverable identity, then layers usage, review-path, default path, and refusal cases. It is dense and long but nearly every clause adds operational value; only minor tightening is possible.

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

Completeness5/5

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. The description covers behavior, refusal conditions, fallbacks, and the finish-the-takeoff workflow, leaving nothing an agent needs to call it correctly unstated.

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

Parameters3/5

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

Schema description coverage is 100%, so all three parameters are already documented in the schema (including default path and overwrite semantics). The description reinforces the default path but adds no syntax or meaning beyond the schema, so the baseline 3 applies.

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

Purpose5/5

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

States a specific verb (writes a PDF to disk) and resource (the MARKED-UP PLANSET deliverable), enumerating its contents: legend cover, per-condition totals, marked sheets. It explicitly distinguishes itself from siblings export_report ('carries the numbers for pricing; this carries the evidence') and export_dxf.

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

Usage Guidelines5/5

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

Gives explicit when-to-use ('finish EVERY takeoff by writing this file and giving the user its path') and names the contrasting alternative (export_report). It also states the review-path alternative for unreviewed machine-traced shapes (import_takeoff payload) and the fallback for encrypted plans (export from the app).

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