Skip to main content
Glama

pcb_unroute

Remove routed tracks, arcs, and vias from selected nets on a focused PCB while preserving footprints, polygons, keepouts, and locked routing unless explicitly included.

Instructions

Take up the focused board's routing: its tracks, arcs and vias.

Removes the free tracks and arcs on signal layers, and the free vias, that carry a net. Never removes a footprint's own copper, polygons or their hatching, dimensions, keepouts, or copper with no net (an antenna, a logo, a heat spreader): those are drawn, not routed. Locked routing stays unless include_locked, since locking is how a designer keeps a route. Polygons are not repoured; pcb_repour_polygons does that.

Refuses unless the focused board is expect_file. With checkpoint (default), first snapshots the board's folder as it is ON DISK, so it can be restored with app_restore_checkpoint; unsaved edits in the editor are not in it, so save first if there are any.

For other selections of board copper, obj_delete and obj_batch_delete take a board type with a filter, e.g. eTrackObject with Layer=TopLayer|InComponent=false.

Args: expect_file: full path of the board to un-route. nets: take up only these nets' routing. None takes every net's. A name that is not a net on the board refuses the whole call and nothing is removed. include_locked: take locked routing as well (default False). checkpoint: take a checkpoint first (default True).

Returns: {"tracks", "arcs", "vias", "nets", "kept_locked", "failed", "checkpoint"}: how many of each were removed, how many nets they were on, and how many locked primitives stayed. Or {"error": ...}.

Input Schema

NameRequiredDescriptionDefault
netsNo
checkpointNo
expect_fileYes
include_lockedNo

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.6.1

TDQS

A5/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: it discloses destructive removal scope, exclusions for footprint copper/polygons/dimensions/keepouts/netless copper, locked-routing behavior, checkpoint semantics, and that an invalid net causes the entire call to refuse with nothing removed. It also clarifies that unsaved editor edits are not included in the checkpoint.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded with the core action and removal scope, then covers exclusions, prerequisite/refusal behavior, checkpointing, alternatives, args, and returns. Every sentence adds operational value for a destructive board operation rather than repeating structured data.

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 absence of annotations, zero schema description coverage, and the destructive nature of the tool, the description is complete enough to call correctly. It covers scope, exclusions, locked handling, checkpoint prerequisites, atomic refusal, alternatives, and 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 it does: expect_file is the board path, nets scopes removal and refuses atomically on an unknown name, include_locked controls locked routing, and checkpoint controls the on-disk snapshot. It adds meaning well 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: taking up routing (tracks, arcs, vias) on the focused board. It precisely defines what is removed and what is never removed, which distinguishes it from general deletion siblings like obj_delete and obj_batch_delete.

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 names alternatives for other board-copper selections (obj_delete and obj_batch_delete with a board type and filter) and points to pcb_repour_polygons for polygon repouring. It also states when the tool refuses to run and when saving is required before checkpointing.

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