Skip to main content
Glama

load_plan

Open a plan PDF from disk into the takeoff session. Replace all prior work by default, or set merge to add the document to the working set while keeping scales, conditions, and shapes.

Instructions

Open a plan PDF from disk. Default: replace the whole session (previous documents, scales, conditions, and shapes are cleared). merge: true ADDS the document to the working set instead (#152) — a bid set is plans + schedule + addenda, not one PDF — keeping every scale, condition, and shape; sheet keys carry file names so documents never collide, the sheet graph spans the whole set (resolve_tag can chain a plan tag on one file to a schedule row in another), and the marked set covers every worked sheet. Re-loading an already-merged file is refused — reload = replace, deliberately. Returns file, files, page_count, and one entry per sheet. The loaded sheets also become browsable resources (takeoff://sheets). Coordinates are image px at render scale 2.0: PDF pt × 2, origin top-left, y down (the browser canvas's native space). Sheet payloads carry dims in both px and pt.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "path": "<path>"
    },
    "name": "load_plan"
  }
}

Input Schema

NameRequiredDescriptionDefault
pathYesPath to a plan PDF on disk
mergeNotrue = ADD this document to the working set, keeping all existing work (merge into an empty session is just a load)

Output Schema

NameRequiredDescriptionDefault
fileYesThe document just loaded (basename)
noteYes
filesYesEvery document in the working set, load order (#152 — one entry unless merge was used)
sheetsYesEVERY sheet in the working set, not just the file loaded by this call
page_countYesTotal sheets across the working set

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed5 schema fields changedv0.1.31
    • removedInput schema / additionalProperties
      Removed value: -false
    • addedOutput schema / properties / page_count / maximum
      Added value: +9007199254740991
    • addedOutput schema / properties / page_count / minimum
      Added value: +-9007199254740991
    • addedOutput schema / properties / sheets / items / properties / page / maximum
      Added value: +9007199254740991
    • addedOutput schema / properties / sheets / items / properties / page / minimum
      Added value: +-9007199254740991
  2. Changed6 schema fields changedv0.1.9
    • addedInput schema / properties / merge
      Added value: +{
      +  "description": "true = ADD this document to the working set, keeping all existing work (merge into an empty session is just a load)",
      +  "type": "boolean"
      +}
    • addedOutput schema / properties / file / description
      Added value: +"The document just loaded (basename)"
    • addedOutput schema / properties / files
      Added value: +{
      +  "description": "Every document in the working set, load order (#152 — one entry unless merge was used)",
      +  "items": {
      +    "type": "string"
      +  },
      +  "type": "array"
      +}
    • addedOutput schema / properties / page_count / description
      Added value: +"Total sheets across the working set"
    • addedOutput schema / properties / sheets / description
      Added value: +"EVERY sheet in the working set, not just the file loaded by this call"
    • changedOutput schema / required
      Previous value: -[
      -  "file",
      -  "page_count",
      -  "sheets",
      -  "note"
      -]New value: +[
      +  "file",
      +  "files",
      +  "page_count",
      +  "sheets",
      +  "note"
      +]
  3. Addedv0.1.5
  4. Removedv0.1.4
  5. Addedv0.1.3
  6. Removedv0.1.2
  7. First observed

TDQS

A4.8/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 behavioral burden and does so thoroughly: it discloses exactly what gets destroyed in replace mode (documents, scales, conditions, shapes), what merge preserves, the collision-safety of sheet keys, the cross-document sheet graph for resolve_tag, and the refusal case. It also surfaces side effects like sheets becoming takeoff://sheets resources.

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 action and the mode switch, then progressively deeper detail. Dense but mostly earning its place; the issue reference "(#152)" and some em-dash parentheticals are minor noise an agent doesn't need.

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 2-parameter but high-consequence session-mutating tool, everything needed is present: mode semantics, refusal behavior, resource side effects, and the coordinate convention (image px at render scale 2.0, origin top-left, y down). Return values are covered by the output schema, so the brief mention of file/files/page_count is sufficient.

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?

Schema coverage is 100%, so the baseline is 3, but the description goes further by explaining the consequences of merge beyond the schema's one-line gloss — retained scales/conditions/shapes, filename-keyed sheets, graph spanning, and the note that merging into an empty session is just a load. The path parameter itself gets no extra semantics beyond "on disk."

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 opening sentence gives a specific verb and resource ("Open a plan PDF from disk") and immediately frames the two operating modes, replace vs merge. An agent can distinguish this from siblings like view_sheet or import_takeoff without reading the 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?

It states the default behavior, the exact condition that selects the alternative (merge: true, with the bid-set rationale of plans + schedule + addenda), and an explicit exclusion: re-loading an already-merged file is refused because reload = replace. When-to-use, when-not, and the alternative are all present.

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