Skip to main content
Glama

design_plan_from_sheet

Reconstruct a validated design plan from an existing schematic sheet so hand-drawn or legacy projects without a canvas file can be edited plan-first instead of symbol by symbol.

Instructions

Read a DesignPlan back off a schematic, including one you did not draw.

Use this when you are asked to change a schematic that has no <project>.canvas.json beside it: a sheet drawn by hand, or one from an older project. It gives you the plan the rest of the design tools take, so an edit becomes "change the plan, lay it out again" instead of dragging symbols around one at a time.

The plan is reconstructed from what is actually drawn: the components give the parts, the compiled netlist gives the nets, and the power-port glyphs say which nets are rails. It is validated before it is returned.

WHAT A SCHEMATIC DOES NOT RECORD, so you must supply it:

  • role on each part. This is the tag that lets the placer recognise a decoupling bank, a crystal cluster, an op-amp motif. A plan without roles lays out noticeably worse. Read the returned part list and netlist and assert the roles yourself before laying it out.

  • zone on each part, if you want functional blocks.

  • Single-pin nets, which the plan schema cannot express. They come back in dropped_pins.

Then: edit the plan, call design_layout_schematic to see it, and design_execute_plan to apply it. Pass design_hints_from_sheet output as placement_hints if you want the existing positions kept.

Args: project_path: The .PrjPcb the sheet belongs to. Its compiled netlist is what supplies the nets. sheet_document: Full path to the .SchDoc to read. Defaults to the active document.

Returns: ok / plan (a DesignPlan dict, or None on a refusal) / parts_read / nets_read / dropped_pins / notes.

Input Schema

NameRequiredDescriptionDefault
project_pathYes
sheet_documentNo

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.6.1

TDQS

A4.7/5.0
Behavior5/5

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

With no annotations provided, the description carries the full behavioral burden and does so well. It explains how the plan is reconstructed, that it is validated before return, what is not recorded (roles, zones, single-pin nets in dropped_pins), and that a refusal returns plan=None.

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 front-loads the core purpose, then uses structured sections for missing information, follow-up steps, args, and returns. Most sentences earn their place, though it is somewhat verbose for a two-parameter tool.

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?

Given the complexity of reconstructing a plan from drawn geometry and netlist data, the description covers the important gaps an agent must know: roles must be supplied, zones optional, dropped pins reported, and edits should flow through layout and execute tools. The output schema exists, but the description still usefully calls out key return fields.

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

Parameters5/5

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

Schema description coverage is 0%, so the description must compensate and does: project_path is documented as the .PrjPcb whose compiled netlist supplies nets, and sheet_document as the full .SchDoc path defaulting to the active document. Both parameters gain meaning beyond their bare names.

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 states a specific verb and resource: it reads a DesignPlan back off a schematic, including hand-drawn or older sheets without canvas metadata. This clearly distinguishes it from nearby design/plan tools by focusing on reconstruction from an existing schematic.

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

Usage Guidelines4/5

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

It gives a clear trigger condition: use it when changing a schematic with no <project>.canvas.json beside it, such as a hand-drawn or older-project sheet. It also explains the follow-up workflow with design_layout_schematic and design_execute_plan, though it does not explicitly name the alternative tool for the canvas.json-present case.

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

Deploy Server

Other Tools