Skip to main content
Glama
ProductOfAmerica

mcp-server-kicad

update_pcb_from_schematic

Update PCB from schematic by importing the netlist, matching footprints by reference, and optionally removing stale unlocked footprints to keep the board synchronized.

Instructions

Update the PCB from the schematic (headless Tools -> Update PCB from Schematic).

Exports the schematic's netlist, loads the assigned footprints from
libraries, and binds every pad to its net. Creates the .kicad_pcb if
it does not exist; new footprints land in a grid cluster. Existing
footprints are matched by reference and keep their position; a
changed footprint assignment swaps the footprint in place. Stale
board footprints are reported, and removed only with delete_stale
(locked ones are never removed). Zones are NOT refilled: run
fill_zones afterward. Net names arrive exactly as KiCad's F8
produces them (local labels sheet-prefixed, e.g. "/SIG"); read them
with list_pcb_nets.

Requires kicad-cli. It no longer needs KiCad's pcbnew Python bindings.

Every byte this writes goes through the server's byte-preserving write, so
a board's format stamp does not move and the parts of it this tool did not
touch arrive unchanged.

Args:
    schematic_path: Path to .kicad_sch file. Optional; omit to use the configured default.
    pcb_path: Path to .kicad_pcb file (created if missing).
        Optional; omit to use the configured default.
    delete_stale: Remove unlocked board footprints absent from the schematic
    project_path: Path to .kicad_pro for explicit root resolution (sub-sheets)

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
pcb_pathNo
delete_staleNo
project_pathNo
schematic_pathNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
addedYes
statusYes
skippedYes
warningsYes
nets_addedYes
pads_boundYes
fpid_changedYes
nets_removedYes
stale_removedYes
value_updatedYes
orphaned_zonesYes
orphaned_tracksYes
stale_footprintsYes
Behavior5/5

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

Annotations only supply false hints, so the description carries the full behavioral burden — and it does so richly: it covers side effects (creates .kicad_pcb if missing), placement behavior (grid cluster), deletion policy (only stale unlocked, locked never removed), zone handling, byte-preserving writes, and the exact net-naming behavior. It even notes what it no longer depends on (pcnew Python bindings).

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?

The description is dense and front-loaded with the essential one-sentence summary, then elaborates with necessary caveats and parameter explanations. Some details pushed the text into a long unformatted paragraph, but every sentence earns its place given the tool's complexity, so a high score is warranted.

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 complex PCB-update tool, the description covers the full lifecycle: purpose, first-run creation, matching/position behavior, deletion semantics, zone refill follow-up, net-naming conventions, dependencies, and byte-level write guarantees. The presence of an output schema means not explaining the return shape is acceptable.

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?

With 0% schema_description_coverage, the description must fully compensate, and it does: every parameter gets semantic meaning (e.g., schematic_path is a .kicad_sch file, optional, falls back to configured default; pcb_path is created if missing; project_path resolves root/sub-sheets). It also adds the 'unlocked' qualifier to delete_stale, which is not in the schema.

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 opens with a precise verb+resource pairing ('Update the PCB from the schematic') and expands it with a concrete mechanism: exports the netlist, loads footprints, and binds every pad to a net. It also distinguishes itself from related tools by explicitly calling out fill_zones and list_pcb_nets as follow-ups, and by stating exactly what it does and does not do.

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 gives explicit guidance: 'Zones are NOT refilled: run fill_zones afterward', 'read them with list_pcb_nets', removal of stale footprints happens only via delete_stale, and it states the prerequisite 'Requires kicad-cli'. These explicit alternates and follow-up instructions make it clear when this tool should be used and what to do instead or next.

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