Skip to main content
Glama
ProductOfAmerica

mcp-server-kicad

autoroute_pcb

Automate PCB trace routing: export the board, run Freerouting, and import the routed traces into a new file without altering the original.

Instructions

Autoroute PCB traces using the Freerouting autorouter.

Exports the board to Specctra DSN format, runs Freerouting for automated
trace routing, and imports the results into a new PCB file. The original
board is never modified.

Requires Java 17+ and KiCad's pcbnew Python bindings, whose major version
has to match the board's format era. On first run, the Freerouting JAR is
auto-downloaded (~20MB).

Args:
    pcb_path: Path to .kicad_pcb file. Optional; omit to use the configured default.
    max_passes: Maximum autorouter optimization passes
    num_threads: Thread count for routing. Defaults to 1 because
        freerouting prints "Multi-threaded route optimization is broken
        and it is known to generate clearance violations" on every run.
        Raise it only if you are willing to DRC the result carefully.
    timeout: Max seconds to wait for routing (default: 600)
    output_dir: Directory for output files (default: same as PCB).
        Optional; omit to use the configured default.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
timeoutNo
pcb_pathNo
max_passesNo
output_dirNo
num_threadsNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
warningsNo
vias_addedYes
routed_pathYes
traces_addedYes
drc_violationsNo
drc_unconnectedNo
keepouts_promotedNo
text_fields_fixedYes
Behavior5/5

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

The description discloses key behavioral traits beyond the annotations: it explicitly states the original board is never modified (important given readOnlyHint=false), mentions the auto-download of the Freerouting JAR (~20MB) on first run, and warns about the multi-threaded routing issue. This adds significant context about side effects and requirements that the annotations alone do not provide.

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 well-structured and front-loaded: the first sentence states the core purpose, followed by a concise workflow summary, then prerequisites, and finally parameter details. Every sentence adds value, and the warning about num_threads is particularly useful. It's appropriately sized for the tool's complexity.

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 tool's complexity (5 parameters, external dependencies, side effects), the description is remarkably complete. It covers the workflow, prerequisites, side effects (auto-download, no modification of original), parameter semantics, and even includes a warning about known issues. The output schema exists, so return values don't need explanation. This is a model description for a complex tool.

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?

The schema has 0% description coverage, so the description must compensate. It does: it explains pcb_path (optional, default), max_passes (optimization passes), num_threads (with detailed warning), timeout (max seconds), and output_dir (default behavior). This adds meaning beyond the schema's basic type/default information, though it could be slightly more explicit about the exact format of pcb_path and output_dir.

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 clearly states the tool's purpose: 'Autoroute PCB traces using the Freerouting autorouter.' It specifies the verb (autoroute), the resource (PCB traces), and the method (Freerouting). It also distinguishes itself from sibling tools like add_trace or remove_traces by describing the full automated routing workflow.

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?

The description provides explicit usage guidance: it explains the workflow (exports to DSN, runs Freerouting, imports results), states that the original board is never modified, and lists prerequisites (Java 17+, matching pcbnew bindings). It also gives specific advice on num_threads, warning about known issues and recommending DRC checks. This clearly helps the agent decide when and how to use the tool.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/ProductOfAmerica/mcp-server-kicad'

If you have feedback or need assistance with the MCP directory API, please join our Discord server