Skip to main content
Glama
Sign In
Copper

Copper

by claynicholson
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

Guided autoroute

pcb_route_guided
Destructive

Routes PCB nets deterministically using a guided plan or built-in heuristics, then validates copper with KiCad DRC and removes rejected tracks. Supports dry runs and comparison.

Instructions

Built-in deterministic router (no download): same plan + same board gives the same copper; KiCad's DRC judges the result and copper it rejects is removed again. No plan = built-in heuristics. plan (all optional, mm, net globs ok): order [nets], global {grid, via_cost, style, layers, time_budget_s, engine: "v2" (default) | "guided"}, nets {"": {priority, width, layers, avoid:[[x0,y0,x1,y1]], corridor:[[x,y],..], max_vias, skip}}, diff_pairs [{p, n, gap, width}], regions [{rect, cost | forbid:true, layers, nets}]. Unknown fields are rejected. ripup: none (default, keep existing tracks) | nets (re-route nets) | all. dry_run / compare never write. Returns routed/total, failed [{net, from, to, reason, where, blocked_by}], per-net length and vias, DRC counts, findings with fixes. A net with a pour only gets the pads the pour misses connected; ground without one is left for pcb_pour. Routing nothing leaves the board untouched. Examples: pcb_route_guided() · pcb_route_guided(ripup="all", plan={"order":["/USB_D?","*"]})

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "pcb_route_guided"
  }
}

Input Schema

NameRequiredDescriptionDefault
netsNoOnly route these nets (names or globs)
planNoRouting heuristics (see description; pcb_route_plan returns the schema and a suggested plan). Omit for built-in defaults.
ripupNonone = keep existing tracks (default); nets = rip up and re-route `nets`; all = rip up every unlocked track first
detailNoFull engine diagnostics (default: compact result)
renderNoattach a PNG (default false)
compareNoScore the existing routing vs. a guided re-route (implies dry_run + ripup='all'); returns both scores and which is better
dry_runNoRoute a scratch copy: full report + picture, board not modified
projectNoproject path (default: active)
while_openNorefuse (default) | revert

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.1.0

TDQS

A3.7/5.0
Behavior4/5

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

Annotations only say destructiveHint=true and openWorldHint=false; the description adds real behavior: determinism guarantees, DRC-rejected copper being removed again, dry_run/compare never writing, 'Routing nothing leaves the board untouched', and pour interaction with pcb_pour. It would be a 5 with explicit note on that the 'all' ripup removes unlocked existing tracks permanently, but ripup and dry_run coverage is close.

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

Conciseness3/5

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

Front-loaded with the key determinism claim and ends with examples, but the middle is a single over-stuffed paragraph mixing router behavior, a mini-schema grammar, an output summary, and edge-case rules. The plan grammar is compressed to the point of being hard to parse ('nets {"<name>": {priority, width, ...' wait here it's a colon) and would be better as a short list.

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 9-parameter, zero-required mutation tool with a nested plan object and no output schema, the description covers safety modes (dry_run, compare, ripup), the plan grammar, and the return shape. Remaining gaps are minor: project/while_open/detail/render semantics live only in the schema, and the destructive effect of ripup='all' is implied rather than spelled out.

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

Parameters4/5

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

Schema coverage is 100% so the baseline is 3; the description goes further by documenting the nested `plan` grammar the schema merely points at (order, global grid/via_cost/style/layers/time_budget_s/engine, per-net priority/width/layers/avoid/corridor/max_vias/skip, diff_pairs, regions) and warning that 'Unknown fields are rejected'. It also expands the return payload (routed/total, failed entries with blocked_by, DRC counts) with no output schema to do that work.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb+resource act: a 'Built-in deterministic router (no download)' whose output is validated by 'KiCad's DRC'. It describes mechanism and outcome clearly, but never names its closest sibling (pcb_route) or explains how it differs, so differentiation is left to inference.

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

Usage Guidelines3/5

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

Gives concrete mode guidance ('No plan = built-in heuristics', 'ripup: none (default...) | nets | all', 'dry_run / compare never write') plus two examples, which implicitly tells an agent when to pick a mode. However, there is no explicit when-not-to-use guidance and no statement of when this beats plain pcb_route or when pcb_route_plan / pcb_pour should run first.

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