mcp-server-kicad

by ProductOfAmerica

Overview Schema Source Related Servers Discussions Admin

Python

Local

autoroute_pcb

Autoroute PCB traces using the Freerouting autorouter.

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 KiCad's pcbnew Python bindings, whose major version has to match
the board's format era, and Java 25+ for the Freerouting build it
downloads. Unless FREEROUTING_JAR names a Freerouting jar, the first run
downloads Freerouting 2.5.0 (65 MB) from GitHub, checks its SHA-256 and
caches it.

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

Name	Required	Description	Default
`timeout`	No
`pcb_path`	No
`max_passes`	No
`output_dir`	No
`num_threads`	No

Output Schema

Name	Required	Description	Default
`warnings`	No
`vias_added`	Yes
`routed_path`	Yes
`traces_added`	Yes
`drc_violations`	No
`drc_unconnected`	No
`keepouts_promoted`	No
`text_fields_fixed`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedv0.20.1Aug 19, 2026
- changedInput schema / properties / num_threads / default
```
Previous value: -4New value: +1
```

Changed1 schema field changedv0.11.0Aug 10, 2026

addedOutput schema / properties / warnings

Added value: +{
+  "items": {
+    "type": "string"
+  },
+  "title": "Warnings",
+  "type": "array"
+}

First observedv0.9.1Jun 10, 2026

TDQS

A4.3/5.0

Behavior4/5

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

Annotations only declare readOnlyHint=false and openWorldHint=true; the description goes well beyond them by disclosing that a new PCB file is created and the original is never modified, the first-run 65 MB network download with SHA-256 verification and caching, and the FREEROUTING_JAR override. It does not quantify runtime cost or describe failure modes (e.g. unrouted nets), which keeps it from a 5.

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?

Well front-loaded — the operation and its non-destructive nature come first, followed by requirements, then a per-argument list. The num_threads explanation spans several lines but each part justifies the default, so the length is largely earned.

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 long-running, network-dependent, multi-stage tool, the description covers side effects, external dependencies, download behavior, and every input; an output schema exists so return values need not be described.

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 coverage is 0%, so the description carries the full burden and does: it documents all five parameters, including defaults, and explains non-obvious semantics (num_threads defaults to 1 due to a known Freerouting multithreading bug producing clearance violations; pcb_path/output_dir fall back to configured 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?

Names a specific verb+resource (autoroute PCB traces) and the engine used (Freerouting), plus the exact pipeline it runs: DSN export, route, import to a new PCB. It is clearly distinguishable from manual trace siblings like add_trace or add_via.

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 practical preconditions (pcbnew binding version match, Java 25+, jar download) and a strong caveat about num_threads, but never states when an agent should choose autorouting versus manual add_trace/place_component workflows, nor what board state is required (e.g. placement complete, netlist valid).

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

Deploy Server