eda-agent

Overview Schema Source Related Servers Discussions Admin

pcb_autoroute

Start a background autorouting job for the focused PCB board using its layout and rules. Poll the job, review DRC results, then apply routed tracks and vias.

Instructions

Route the focused board with the in-house layout engine, as a job.

Reads the board exactly (pcb.get_layout_model: padstacks per layer, rules, pours, planes, in Altium's internal units), then routes it in the background and returns a job id at once. Poll design_job_status; design_job_result gives the tracks and vias to add, the exact DRC's verdict on the routed board, and which pours it relied on as planes. Nothing is written to the board until pcb_autoroute_apply.

This is the in-house engine: no Altium autorouter, no external program. Inner layers a pour covers are used as planes and not routed on; a redundant one is given back to routing when the board cannot be completed without it.

With the stage switches on, the routing runs in planned stages, each one's copper fixed for the next: differential pairs (coupled at their gap, skew evened with bumps), a dog-bone via for every pad a plane or pour joins (never a via in a passive's pad; an exposed pad gets a via array), access lanes kept straight out of fine-pitch IC pins, buses laid as nested lanes, then everything else negotiated, high-current nets first, then rails, then the rest. Every bend is 45 degrees or less, and no via goes into a passive's pad. Over 160 finished boards these defaults routed 98.93% mean against 98.85% for the router before the stages (two boards fewer at 100%, all DRC-clean, about 29% more time); plane fanout is off by default because it cost completion. With all four switches off this is the router before the stages, exactly.

Args: expect_file: full path of the board to route. The read refuses on the first reply if the focused board is another one. nets: route only these nets; all other copper stays as it is. None routes every net with two or more pads. use_planes: treat inner layers a single pour covers as planes (default True). diff_pairs: route the board's differential pairs (its own definitions, else read from _P/_N, +/-, DP/DM net names) as coupled pairs first (default True). plane_fanout: give every surface pad of a plane or pour net its dog-bone via before the signals (default False). pin_lanes: keep the first 0.8 mm straight out of each IC pin at 0.65 mm pitch or finer for that pin's own net (default True). bus_lanes: lay three or more nets between the same two parts as one group of nested lanes (default True).

Returns: {"job_id", "board", "read": {pads, components, nets, layers}}, or {"error": ...} when the read failed or found another board. The job's result adds, beside the copper and the DRC verdict: via_in_pad (every via in a pad, for the fab notes: filled and capped), pairs (per pair: lengths, skew, bumps, layer changes, or why it was left to the router), buses (per bus: its lanes, what was ripped up and planned again, or why not), and unreached (every pad left unrouted, with its place and the nets in its way).

Input Schema

Name	Required	Description	Default
`nets`	No
`bus_lanes`	No
`pin_lanes`	No
`diff_pairs`	No
`use_planes`	No
`expect_file`	Yes
`plane_fanout`	No

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.6.1Oct 29, 2026

TDQS

A4.7/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 so thoroughly: asynchronous job semantics, immediate return of a job id, deferred mutation gated behind a separate apply tool, refusal when expect_file mismatches the focused board, plane layers being excluded from routing but reclaimable when completion fails, and empirical completion stats (98.93% mean vs 98.85%). This is exactly the behavioral context annotations would otherwise need to supply.

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?

Front-loaded with purpose and the job/apply lifecycle, then cleanly sectioned into behavior, Args, and Returns. The middle paragraph on planned stages is dense and the benchmark statistics are verbose, but nearly every sentence informs a routing decision or a switch setting, so little is truly wasted.

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 7-parameter, no-annotation, async mutation tool, nothing an agent needs is absent: inputs, defaults, job lifecycle, what the result payload adds (via_in_pad, pairs, buses, unreached), and the safety boundary at pcb_autoroute_apply. It even documents return values despite an output schema existing.

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% across 7 parameters, so the Args block is doing all the work — and it does: each switch is explained in terms of its routing effect (pairs coupled at gap with skew bumps, dog-bone via per plane-joined pad, 0.8 mm pin lanes at 0.65 mm pitch, nested bus lanes), with defaults stated. expect_file's mismatch behavior and nets' None semantics are both documented.

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?

Opens with a specific verb and resource ("Route the focused board with the in-house layout engine, as a job") and immediately distinguishes itself from the write step by naming pcb_autoroute_apply and the design_job_* polling siblings. An agent can tell this apart from route_plan or pcb_autoplace without opening any schema.

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

Usage Guidelines4/5

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

Spells out the workflow explicitly: this call returns a job id at once, poll design_job_status, read copper/DRC from design_job_result, and nothing touches the board until pcb_autoroute_apply. It also gives a clear default-recommendation for the stage switches (plane_fanout off by default because it cost completion). What's missing is any "when not to use this" — e.g. when route_plan or pcb_unroute should be preferred — but the context is otherwise clear.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server