Skip to main content
Glama

route_plan

Automatically routes PCB tracks and vias offline using A* pathfinding. Specify net names and routing rules to generate a complete, validated board plan.

Instructions

Route the board offline (grid A*) and return placeable ops.

Pure Python -- no Altium round-trip unless fetch_geometry is set. Output tracks are {x1, y1, x2, y2, width, layer, net_name} (the pcb_place_tracks item shape) and vias are {x, y, net, size, hole_size} (the pcb_place_via params), integer mils, so the result applies verbatim. Per-net failure is honest data (status failed), not a tool error.

Live sequence: fetch geometry -> this tool -> pcb_place_tracks / pcb_place_via -> pcb_run_drc -> route_plan_repairs -> apply -> repeat.

Args: geometry: Gen_GetPcbGeometry payload (bbox / outline / pads / tracks / vias, all mils). Pads and copper of nets NOT being routed stay in the obstacle map. rules: Routing rules, all mils -- clearance_mils, track_width_mils (int, or per-class dict with "default"), via_size_mils, via_drill_mils, layers (default TopLayer + BottomLayer). None uses defaults. nets: Route only these net names; everything else stays a static obstacle. Unknown names are reported in unknown_nets. None routes every netted pad group. net_classes: Net name -> class (power / ground / differential / ...). Sets routing order and the per-class track width. Unlisted nets are signal. grid_pitch_mils: Routing grid pitch in mils (default 25). bend_penalty: A* corner cost in grid-pitch units. via_cost: A* layer-change cost in grid-pitch units. max_expansions: Per-connection A* budget so a walled-in net fails fast. fetch_geometry: When True and geometry is None, pull the live board over the bridge.

Returns: {"ok": True, "summary": {nets_total, routed, failed, skipped, completion, track_count, via_count, total_length_mils}, "order": [...], "nets": {net: {status, class, width, tracks, vias, ...}}, "tracks": [...], "vias": [...], "validation": {...}}; with a nets filter also requested_nets / unknown_nets. {"ok": False, "reason": ...} on malformed input.

``geometry`` says which board state was planned against:
``source`` is ``live`` when this call read the board and
``caller`` when you supplied the dict, plus the ``bbox`` and
``counts`` from that payload. A ``caller`` plan is only as
current as the snapshot behind it, and this tool cannot date
it: after placing anything, re-read before re-planning or
the next plan routes through copper it cannot see.

Input Schema

NameRequiredDescriptionDefault
netsNo
rulesNo
geometryNo
via_costNo
net_classesNo
bend_penaltyNo
fetch_geometryNo
max_expansionsNo
grid_pitch_milsNo

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 burden and does: it discloses offline/pure-Python computation, that output objects match pcb_place_tracks/pcb_place_via item shapes and apply verbatim in integer mils, that per-net failure is returned as status 'failed' rather than a tool error, that malformed input yields {ok: False, reason}, and that geometry.source reveals whether the plan ran against a live read or a caller-supplied (un-datable) snapshot.

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?

It is front-loaded with the purpose and workflow, and nearly every sentence carries non-obvious information (shape contracts, failure semantics, staleness). It is long and docstring-shaped, though, and the Returns block restates much of what the output schema already provides, which is the main trimming opportunity.

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 9-parameter routing engine with zero schema coverage, the description supplies everything an agent needs: data contracts for inputs and outputs, workflow position, failure modes, and the staleness trap that would otherwise cause silently bad plans. The output schema exists, so return-value detail is supplementary rather than required.

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% and there are 9 parameters, so the description must compensate, and it documents every one: geometry payload contents, rules sub-keys (clearance_mils, track_width_mils, via_size_mils, via_drill_mils, layers), nets filtering plus unknown_nets behavior, net_classes routing order and per-class width, grid_pitch_mils, bend_penalty, via_cost, max_expansions, and fetch_geometry, including defaults.

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 first sentence gives a specific verb, resource, and method: 'Route the board offline (grid A*) and return placeable ops.' It then distinguishes itself from the Altium-side autoroute siblings by stating 'Pure Python -- no Altium round-trip unless fetch_geometry is set,' so an agent can tell it apart from pcb_autoroute/pcb_autoroute_apply without opening a 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 spells out the live sequence explicitly (fetch geometry -> this tool -> pcb_place_tracks/pcb_place_via -> pcb_run_drc -> route_plan_repairs -> apply -> repeat) and states the condition that selects each mode (fetch_geometry True vs. supplying a geometry dict). It also gives the critical exclusion: after placing anything, re-read before re-planning.

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