Skip to main content
Glama

design_execute_plan

Instantiates a DesignPlan in Altium by emitting a batched schematic from Python or using the legacy IPC executor. Accepts placement hints and edit modes so refined or changed plans apply without redrawing hand-edited sheets.

Instructions

Instantiate a DesignPlan in Altium.

Two execution paths:

  • use_canvas=True (default): the new canvas-based pipeline. Plan -> SymbolExtractor -> SchematicCanvas (all in Python) -> one-shot batched emit to Altium. Layout decisions are made before any IPC; an SVG preview is written next to the project file so you can sanity-check the schematic without opening it.

  • use_canvas=False: the legacy executor that interleaves layout with Altium IPC. Kept as a fallback while the new path stabilises.

Both halt early if the plan contains any needs_creation parts. Resolve those first by either picking an existing-lib equivalent or branching into a library-authoring sub-task.

Args: plan_json: Either a DesignPlan JSON string, or the DesignPlan as a JSON object/dict. The MCP framework auto-deserializes JSON-object literals to dicts before the tool sees them, so both shapes are accepted. project_path: Absolute path to the target .PrjPcb. Created if it does not exist. use_canvas: Pick the execution path. Default True runs the new canvas pipeline; pass False to fall back to the legacy executor. placement_hints: Optional {refdes: {"x": int, "y": int, "rotation": int}} partial anchors. Hinted refdes pin to the supplied position; others run through the algorithmic placement (Sugiyama + multi-try scoring). Used by the agent-in-loop refinement workflow: 1. Run design_preview_plan -> see SVG + score. 2. If layout is bad, identify specific refdes that should sit elsewhere; build hints dict. 3. Call design_preview_plan again with hints -> iterate until score is acceptable. 4. Call design_execute_plan with the same hints to emit the refined layout. mode: How to reach the sheet. "auto" (default) EDITS a sheet this tool has drawn before, moving only the parts whose position changed, placing the new ones, deleting the ones the plan dropped, and leaving every other component exactly as it is. It draws from scratch when there is no prior sheet. This is what makes re-running a changed plan safe on a schematic somebody has worked on. "full" re-places every component, discarding any hand edit; use it when you want the sheet redrawn. "delta" refuses rather than redraw.

    The edit path only knows what is in the plan. To keep a
    part where a person dragged it, read the sheet back with
    ``design_hints_from_sheet`` and pass the result as
    ``placement_hints``.

Returns: Result dict with ok / project_path / sheets_touched / placed (list of placements) / failures / needs_creation / notes. Canvas-path additions: canvas (the SchematicCanvas dict snapshot) and preview_svg_path (where the SVG was written). On an edit, delta lists the refdes added, moved, replaced, removed and untouched; placed then covers only the parts actually placed, which on an edit is the new ones.

Input Schema

NameRequiredDescriptionDefault
modeNoauto
plan_jsonYes
use_canvasNo
project_pathYes
placement_hintsNo

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.6.1

TDQS

A4.9/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 early halting on needs_creation, SVG preview output, that auto edits an existing sheet safely, that full discards hand edits, that delta refuses, and that the edit path only knows what is in the plan. These are exactly the mutation and fallback behaviors an agent needs before invoking a write tool.

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 front-loaded with the two execution paths and then moves through args and returns in a predictable structure. It is longer than necessary in places, particularly repeating use_canvas details and including a Returns section despite an existing output schema, but the length is largely justified by the tool's complexity.

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 complex five-parameter mutation tool with no annotations, the definition covers all parameters, execution-path behavior, early-exit conditions, placement refinement workflow, mode semantics, and return values. An agent has enough information to call it correctly and to know when to use sibling tools first.

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 it does: plan_json accepted shapes, project_path semantics including creation, use_canvas default and path choice, placement_hints structure and refinement workflow, and mode enum meanings are all explained. This adds substantial meaning beyond the bare schema.

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: instantiate a DesignPlan in Altium. It distinguishes the canvas and legacy execution paths and references sibling tools such as design_preview_plan and design_hints_from_sheet, so an agent can identify its role without opening 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 explicitly documents when to use use_canvas=True versus False, what mode="auto"/"full"/"delta" do, and when to stop because of needs_creation parts. It also gives a concrete agent-in-loop workflow with design_preview_plan and design_hints_from_sheet for placement refinement.

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