Skip to main content
Glama

export_marked_pdf

Writes a distribution-ready marked-up plan PDF with condition totals, quantity chips, annotations, and approval marks so takeoff results can be shared as visual evidence.

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. Every page carries a light diagonal "OpenTakeoff" and the line "Prepared with OpenTakeoff · opentakeoff.kentucky-ai.com". 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.

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": "export_marked_pdf"
  }
}

Input Schema

NameRequiredDescriptionDefault
pathNoWhere to write the PDF (default: "<plan dir>/<plan> - marked set.pdf")
overwriteNoReplace 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_nameNoCover-page project name (default: the plan file's name)

Output Schema

NameRequiredDescriptionDefault
noteYes
pathYesAbsolute path of the written marked-set PDF — hand this to the user
pagesYesLegend cover + the RFI schedule page(s) when any RFI is live + one page per marked sheet
rfis_printedYesLive RFIs printed on the RFI schedule page (#364) — agent-raised and panel-raised alike; withdrawn ones leave a numbering gap
shapes_drawnYes
sheets_markedYesSheets carrying shapes, annotations, or approval marks — unmarked sheets are omitted
approvals_drawnYesApproval-family glyphs burned in (#176) — estimator APPROVED rings + agent AGENT diamonds; the cover tallies the split when any exist
annotations_drawnYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed13 schema fields changedv0.1.31
    • removedInput schema / additionalProperties
      Removed value: -false
    • addedOutput schema / properties / annotations_drawn / maximum
      Added value: +9007199254740991
    • addedOutput schema / properties / annotations_drawn / minimum
      Added value: +-9007199254740991
    • addedOutput schema / properties / approvals_drawn / maximum
      Added value: +9007199254740991
    • addedOutput schema / properties / approvals_drawn / minimum
      Added value: +-9007199254740991
    • addedOutput schema / properties / pages / maximum
      Added value: +9007199254740991
    • addedOutput schema / properties / pages / minimum
      Added value: +-9007199254740991
    • addedOutput schema / properties / rfis_printed / maximum
      Added value: +9007199254740991
    • addedOutput schema / properties / rfis_printed / minimum
      Added value: +-9007199254740991
    • addedOutput schema / properties / shapes_drawn / maximum
      Added value: +9007199254740991
    • addedOutput schema / properties / shapes_drawn / minimum
      Added value: +-9007199254740991
    • addedOutput schema / properties / sheets_marked / maximum
      Added value: +9007199254740991
    • addedOutput schema / properties / sheets_marked / minimum
      Added value: +-9007199254740991
  2. Changed3 schema fields changedv0.1.21
    • 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"
      +]
  3. Changed1 schema field changedv0.1.15
    • 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"
      +}
  4. Changed3 schema fields changedv0.1.12
    • 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"
      +]
  5. Addedv0.1.9

TDQS

A4.3/5.0
Behavior4/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 well: it discloses page contents, the per-page watermark, the default output path, the last-page caveat for machine-traced shapes, and that no native canvas is required. The only real gap is that it never mentions permission needs, runtime cost, or what the tool returns on success (though an output schema exists, so the latter is excusable).

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 purpose and the imperative to call it are front-loaded, which is good, but the single dense paragraph is overstuffed: watermark text, module-provenance claims, and rhetorical lines like "a construction takeoff is no good without markup" consume space an agent doesn't need. The refusal case and default path are buried mid-paragraph rather than structured separately.

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?

For a zero-required-parameter export tool with an output schema, this covers everything an agent needs: when to call it, where the file lands, what it contains, the encrypted-PDF refusal, and the review path via export_takeoff. Nothing material is missing.

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 the schema already documents path, overwrite, and project_name thoroughly — including the overwrite semantics. The description adds only a restatement of the default path and the overwrite caveat, which the schema already states; it adds no new meaning about parameter interaction or edge cases.

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?

The description opens with a specific verb+resource: writes a distribution-ready PDF containing a legend cover and every marked sheet, vector-copied from the source plan. It explicitly distinguishes itself from the closest siblings ("export_report carries the numbers for pricing; this carries the evidence") and from export_takeoff, so an agent can route without opening any schema.

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?

States an explicit call condition — "finish EVERY takeoff by writing this file and giving the user its path" — and names the alternatives with their division of labor. It also gives a when-not path for the one refused source (encrypted plan PDFs) and names the fallback: export from the app or supply an unencrypted PDF.

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