kicad-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| JAVA_PATH | No | Path to the Java executable used for Freerouting. | |
| KIKIT_PATH | No | Path to KiKit. | |
| NGSPICE_PATH | No | Path to the ngspice executable. | |
| KICAD_CLI_PATH | No | Path to the KiCad 10 kicad-cli executable. Required tool; this environment variable overrides PATH and usual install locations. | |
| KICAD_DEMOS_DIR | No | Path to KiCad's demo projects directory. | |
| KICAD_SYMBOL_DIR | No | Path to KiCad's symbol libraries directory. | |
| KICAD_PYTHON_PATH | No | Path to KiCad's bundled Python, used for Freerouting Specctra export/import and KiKit. | |
| FREEROUTING_JAR_PATH | No | Path to the Freerouting 2.5.0 jar. | |
| KICAD_MCP_JLCPCB_LIBRARY | No | Path to a JLCPCB symbol and footprint library checkout. | |
| KICAD_ROUTING_TOOLS_PATH | No | Path to the KiCadRoutingTools checkout. | |
| KICAD_ROUTING_TOOLS_PYTHON | No | Python executable used to run KiCadRoutingTools. |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| list_toolsetsA | List available KiCad tool groups (schematic, pcb, sourcing, ...) and whether each is currently loaded. |
| load_toolsetA | Load a tool group's tools into this session, e.g. 'sourcing', 'schematic', 'pcb', 'verification'. |
| unload_toolsetB | Unload a tool group's tools to free up the session's tool-schema budget. |
| verify_boardA | The acceptance gate. Grades a board with real kicad-cli (three refilled runs, union of errors) and returns PASS, FAIL or INCOMPLETE plus the COMPLETE per-net unconnected list and the complete violation list. Only a PASS may be reported as routed or done. parity: "required" (a missing or unannotated schematic, or one with stale instance paths, is INCOMPLETE) or "not_applicable" (give parity_reason, e.g. an imported board with no schematic). baseline: the dict from pin_rule_baseline. Without it the verdict is INCOMPLETE, because rule weakening (.kicad_dru severity ignore, rule_severities) would go unseen. FAIL takes precedence over INCOMPLETE. incomplete_reasons say why a verdict is INCOMPLETE. notes are informational hints (e.g. the units of one part disagree on DNP): they are never reasons and never change the verdict, so a note neither doubts a PASS nor excuses a FAIL or INCOMPLETE. |
| pin_rule_baselineA | Snapshot the rule settings verify_board grades against (rule severities, netclass
limits, .kicad_dru severity clauses, ignored checks). Read-only: the caller stores the
result and passes it as |
| propose_input_preparationA | Dry run of input preparation: lists every copper-layer text (F.Cu/B.Cu gr_text) that would move to silkscreen, and returns a revision_token. Writes nothing. Run this step once per board, BEFORE pin_rule_baseline and before any routing; never
inside a routing attempt. Copper text it cannot handle (inner-layer text, text boxes) is
listed under output_dir: new directory for the prepared project copy (default: sibling
|
| confirm_input_preparationA | Apply a proposal from propose_input_preparation: writes a NEW prepared board revision
(the source is untouched), re-pins the rule baseline on it and reports the Runs once per board, BEFORE the pin_rule_baseline you use for routing, never inside an
attempt: use the returned parity: "required" or "not_applicable" (give parity_reason), passed to the gate unchanged. |
| propose_pour_stepA | Dry run of the pour step: validates the requested power planes and returns a revision_token. Writes nothing and runs no router. pours: {net name: copper layer}, one net per layer, e.g. {"GND": "B.Cu"}. A net that
already has a pour on that layer is skipped. Run propose_input_preparation /
confirm_input_preparation first (copper-layer text is refused by confirm), then
pin_rule_baseline, then this step once, before routing signals. output_dir: a new
directory (default sibling |
| confirm_pour_stepA | Run the plane router on a scratch copy of the board, grade its candidate, and only if accepted write a NEW board revision with the zone (plus any vias/tracks the plane script added); the source is untouched. The revision_token is single use. baseline: the dict from pin_rule_baseline, REQUIRED (this step never pins silently; an empty baseline is refused as incomplete). Input preparation (propose_input_preparation) must have run first: a board with copper-layer text is refused. What status Cost per confirm: about 12 gate runs (kicad-cli DRC) plus connectivity runs, capped at 40 in total; expect minutes, not seconds. Over the cap a pad is never accepted unproven. In the result, pcb_path is the new revision (same as output_pcb) and source_pcb is the board you passed in; both gates are stale until verify_board runs on the revision. |
| propose_schematic_importA | Dry run of importing footprints and nets from the project's schematic into the board (Update PCB from Schematic): lists every footprint and net that would be added and where new footprints are staged; writes nothing and returns a revision_token. Any footprint that cannot be resolved through the project fp-lib-table / installed libraries blocks the proposal (status blocked, no token) and is named. Staged footprints are not placed: placement is a separate step. schematic_path defaults to the board's own .kicad_sch; staging_origin is [x, y] in page mm (default: right of the Edge.Cuts box). Order for a project: import_from_schematic -> board_outline -> board_rules -> input_preparation -> silkscreen_minimums -> pin_rule_baseline -> pour step -> routing. Every confirm writes a NEW board revision beside the source (the source is untouched) and returns it as output_pcb (also pcb_path; the board you passed in is source_pcb): continue from that path. Both gates are stale until verify_board runs; only verify_board certifies. |
| confirm_schematic_importA | Apply a propose_schematic_import proposal: writes a NEW board revision with the schematic's footprints and every pad net, verified by a fresh reload against the kicad-cli netlist; an unresolved footprint fails the whole confirm and nothing is written. The revision_token is single use. Order for a project: import_from_schematic -> board_outline -> board_rules -> input_preparation -> silkscreen_minimums -> pin_rule_baseline -> pour step -> routing. Every confirm writes a NEW board revision beside the source (the source is untouched) and returns it as output_pcb (also pcb_path; the board you passed in is source_pcb): continue from that path. Both gates are stale until verify_board runs; only verify_board certifies. |
| propose_board_rulesA | Dry run of setting the board's design rules (minimum clearance, track width, via diameter, via annular width, through-hole diameter, and named net classes with their nets) in the project's .kicad_pro; lists every value that would change, every loosening and every incoherence; writes nothing and returns a revision_token. Lengths are mm. A key absent from the project counts as KiCad's built-in default, never as unset. netclasses: [{name, clearance?, track_width?, via_diameter?, via_drill?, priority?, nets?: [exact net names]}]. allow_loosen: lowering a rule is refused unless this is true; set only after a human has read the listed items; never set it to get past a refusal on your own. allow_incoherent: a class value below a board minimum is refused unless this is true; set only after a human has read the listed items; never set it to get past a refusal on your own. Order for a project: import_from_schematic -> board_outline -> board_rules -> input_preparation -> silkscreen_minimums -> pin_rule_baseline -> pour step -> routing. Every confirm writes a NEW board revision beside the source (the source is untouched) and returns it as output_pcb (also pcb_path; the board you passed in is source_pcb): continue from that path. Both gates are stale until verify_board runs; only verify_board certifies. |
| confirm_board_rulesA | Apply a propose_board_rules proposal: writes a NEW project revision with the rules, verified by a fresh reload, then pins the rule baseline of that revision and grades it (the |
| propose_board_outlineA | Dry run of replacing the board outline (one rectangle, optional rounded corners) and adding mounting holes with copper keepouts; lists what would be replaced, which footprints would fall outside the new outline (reported, never moved) and any hole that touches existing items; writes nothing and returns a revision_token. outline: {x, y, width, height, corner_radius?} in mm. mounting_holes: [{reference, x, y, keepout_radius_mm, footprint?}]. origin: "page" (file coordinates, default) or "aux_axis" (relative to the board's aux axis origin). allow_overlap: a hole whose keepout touches footprints, tracks, vias, zones or another hole is refused unless this is true; set only after a human has read the listed items; never set it to get past a refusal on your own. Order for a project: import_from_schematic -> board_outline -> board_rules -> input_preparation -> silkscreen_minimums -> pin_rule_baseline -> pour step -> routing. Every confirm writes a NEW board revision beside the source (the source is untouched) and returns it as output_pcb (also pcb_path; the board you passed in is source_pcb): continue from that path. Both gates are stale until verify_board runs; only verify_board certifies. |
| confirm_board_outlineA | Apply a propose_board_outline proposal: writes a NEW board revision with the outline and mounting holes, verified by a fresh reload and a kicad-cli outline check; copper pours under a new keepout need refilling before any pour or DRC figure means anything. The revision_token is single use. Order for a project: import_from_schematic -> board_outline -> board_rules -> input_preparation -> silkscreen_minimums -> pin_rule_baseline -> pour step -> routing. Every confirm writes a NEW board revision beside the source (the source is untouched) and returns it as output_pcb (also pcb_path; the board you passed in is source_pcb): continue from that path. Both gates are stale until verify_board runs; only verify_board certifies. |
| propose_silkscreen_minimumsA | Dry run of raising every silkscreen text below the fab minimums (height and stroke) on a NEW revision; lists each text with its before and after size, and any text it cannot handle under |
| confirm_silkscreen_minimumsA | Apply a propose_silkscreen_minimums proposal: writes a NEW board revision with the raised text, verified by a fresh reload against the plan. The revision_token is single use. Order for a project: import_from_schematic -> board_outline -> board_rules -> input_preparation -> silkscreen_minimums -> pin_rule_baseline -> pour step -> routing. Every confirm writes a NEW board revision beside the source (the source is untouched) and returns it as output_pcb (also pcb_path; the board you passed in is source_pcb): continue from that path. Both gates are stale until verify_board runs; only verify_board certifies. |
| project_createC | Scaffold a new KiCad project: .kicad_pro, blank .kicad_sch, blank .kicad_pcb. |
| project_openB | Open an existing KiCad project and summarize its schematic/PCB contents. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 19 tools
The propose_/confirm_ pairing gives each operation a clear dry-run vs apply boundary, and verify_board is repeatedly (and correctly) framed as the single verdict tool, which resolves most confusion. A few pairs still sit close together: propose_input_preparation (moving copper text to silkscreen) vs propose_silkscreen_minimums (resizing text) both operate on the same board text, and the baseline pinning happens implicitly inside confirm_board_rules / confirm_input_preparation as well as in pin_rule_baseline.
The dominant pattern is verb_noun (verify_board, pin_rule_baseline, load_toolset), and the six propose_/confirm_ pairs are perfectly parallel. Deviations are minor but real: project_create/project_open reverse to noun_verb, list_toolsets uses a plural where load_toolset/unload_toolset use singular, and only the pour pair carries a '_step' suffix.
19 tools is on the heavy side, but half of them are the six propose/confirm pairs, which exist so that irreversible board writes require a dry run first — that doubling is justified by the domain rather than redundant. The five orchestration tools (list/load/unload_toolset, pin_rule_baseline, verify_board) and two project tools each carry a distinct role.
The visible surface covers a coherent forward pipeline (scaffold, outline, rules, schematic import, input prep, silkscreen, pour, verify) with no way to undo or remove anything once written. The documented stage order explicitly names 'routing' after the pour step, yet no routing tool appears here — it must come from a dynamically loaded toolset — and there is no export/manufacturing output (gerbers, drill, BOM) or board-inspection tool beyond project_open's summary.