Skip to main content
Glama

design_layout_schematic

Compute schematic layout geometry as pure data from a DesignPlan to inspect placements, wires, and scores offline without touching Altium.

Instructions

Compute the schematic layout for a DesignPlan, as pure data.

THE ONE SCHEMATIC ENGINE. Every schematic tool now runs the same canvas pipeline, so whenever you are asked to draw or lay out a schematic, reach for this family and nothing else: this tool for the geometry as data, design_preview_plan for the same layout rendered to SVG, design_execute_plan to place it in Altium. There is no longer a second engine to choose between.

It used to run a second, standalone engine whose placements and score described a layout nobody would ever see. That engine is no longer reachable: measured over ten held-out corpus sheets it lost the shared objective on seven and produced four pairs of OVERLAPPING BODIES where this pipeline produced none, so the shorter wire it appeared to draw was partly bought by stacking parts on top of one another.

Runs OFFLINE and never reaches Altium, so it works on every backend. That costs one thing and the result says which: symbol geometry is synthesised from the plan's pin lists rather than read from a library, so symbols comes back "synthetic" and execution_accurate is False. The placement and routing RULES are the ones that execute. When you need the exact geometry, use design_preview_plan (same pipeline, real symbols, renders SVG) or design_execute_plan to emit.

Args: plan_json: A DesignPlan as a JSON string or a JSON object/dict. sheet: Sheet name to report (default "main"). grid_mils: Accepted for compatibility; the canvas pipeline snaps to its own 100-mil grid. fr_iterations: Accepted for compatibility; the pipeline sweeps its own force-directed budget and scores the results. placement_hints: Optional {refdes: {"x", "y", "rotation"}} pinned positions, same as design_execute_plan. render_png: Optional path for a preview image of the layout.

Returns: Dict with ok / sheet / engine ("canvas") / execution_accurate (True) / summary / placements / net_representation / wires / net_labels / power_ports / junctions / score / notes / failures. On a bad plan: {"ok": False, "errors": [...]}.

Input Schema

NameRequiredDescriptionDefault
sheetNomain
grid_milsNo
plan_jsonYes
render_pngNo
fr_iterationsNo
placement_hintsNo

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.6.1

TDQS

A4.4/5.0
Behavior3/5

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

The description discloses important behavior absent from annotations: it runs offline, never reaches Altium, synthesizes symbols from pin lists, and returns synthetic symbols. However, it internally contradicts itself by saying execution_accurate is False earlier and then listing execution_accurate (True) in the Returns section, which is a material inconsistency for an agent interpreting results.

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 core routing decision and uses clear sections for engine behavior, arguments, and returns. It is somewhat long and includes historical benchmark narrative about the removed engine that is not essential for invocation, but the structure remains usable.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a complex tool with no annotations and 0% schema description coverage, the description is largely complete: it covers offline execution, synthetic symbols, arguments, and error behavior. The main gap is the self-contradictory execution_accurate value, which prevents it from being fully reliable.

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 carry parameter meaning, and it does document all six arguments. It explains plan_json as a JSON string or object, sheet as a report target, grid_mils and fr_iterations as compatibility arguments, placement_hints as pinned refdes positions, and render_png as a preview path.

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: compute the schematic layout for a DesignPlan as pure data. It explicitly distinguishes this tool from design_preview_plan (SVG) and design_execute_plan (Altium placement), so an agent can identify it without opening sibling schemas.

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 gives explicit routing guidance: use this family for schematic drawing/layout, this tool for geometry as data, design_preview_plan for rendered SVG, and design_execute_plan for Altium emission. It also states that there is no second engine to choose between.

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