Skip to main content
Glama

import_takeoff

Merge a takeoff canvas file into the current session to resume, extend, or audit takeoffs, with reviewed shapes preserved and session calibration applied.

Instructions

The way BACK IN (#151): load an "opentakeoff.takeoff_canvas.v1" file — a prior export_takeoff, or the app's own save — into this session, through the SAME tested merge rules as the app's Sheet-menu import: finish-tag identity joins imported conditions onto this session's own (their knobs win), new ids append, duplicate ids skip (re-import is idempotent), and THIS session's calibration wins per sheet. An empty session adopts the file wholesale. Resume yesterday's work, extend a takeoff a human already reviewed (their ink stays ink — reviewed shapes arrive untouchable by agent verbs), or audit someone else's export with list_shapes/takeoff_summary. Requires a loaded plan; shapes referencing OTHER files ride along and count in totals but can't be viewed against this document — the reply's unknown_files names them. Approval marks ride the file too — transport, not minting: an estimator seal arriving by import stays estimator ink, listable but untouchable here. undo_last removes the imported SHAPES as one step; adopted conditions, scales, annotations, and approval marks stay.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
pathYesPath to a takeoff_canvas.v1 JSON file on disk

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
fileYesBasename of the imported file
noteYes
replacedYestrue = the session was empty and adopted the file wholesale
shapes_addedYes
shapes_totalYes
unknown_filesYesFiles referenced by imported shapes that this document doesn't have — they count in totals but can't be viewed here
rules_importedYesCorrection rules (#88) that arrived with the file — apply_rules re-runs them
scales_adoptedYesSheets whose calibration came from the file (this session's own always wins)
shapes_pendingYesOf the added shapes, how many are unreviewed machine pencil
conditions_addedYes
conditions_mergedYesImported conditions that joined an existing finish tag (its knobs won)
Behavior5/5

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

With no annotations provided, the description carries the full burden and does so richly: it discloses merge rules (finish-tag identity, duplicate skip, idempotency), calibration precedence, reviewed-shape protection, unknown_files behavior, approval-mark transport, and undo semantics. No annotation contradiction exists.

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?

The description is long but appropriately dense, with each sentence carrying meaningful behavioral or usage information. The opening 'The way BACK IN (#151)' is slightly cryptic but not harmful; overall it is well-structured and front-loaded.

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?

Covers all necessary context: preconditions, merge behavior, return field (unknown_files), limitations with other-file shapes, and undo impact. Given the complexity and the existence of an output schema, the description is fully self-sufficient.

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 coverage is 100% for the single 'path' parameter, and the description does not add significant new parameter-level detail beyond referring to the file type already in the schema. 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?

The description clearly identifies 'load an opentakeoff.takeoff_canvas.v1 file' into the session, specifying the exact file type and operation. It distinguishes itself from siblings by naming export_takeoff as the counterpart and load_plan as a different resource (plan vs canvas).

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?

Explicitly lists use cases: 'Resume yesterday's work, extend a takeoff a human already reviewed... or audit someone else's export with list_shapes/takeoff_summary.' Also states the prerequisite 'Requires a loaded plan' and references the Sheet-menu import as an alternative with the same merge rules.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/Kentucky-ai/opentakeoff'

If you have feedback or need assistance with the MCP directory API, please join our Discord server