MCP for Hardware: Connect Your Editor to a PCB Pipeline

What MCP connects

Model Context Protocol (MCP) gives an editor or coding agent a typed interface to another process. In a PCB workflow, that other process can inspect a KiCad project, run checks, or produce review artifacts. The useful boundary is not “let the model run any terminal command.” It is “offer a small set of PCB operations whose inputs, outputs, and side effects are explicit.”

A local setup has four parts:

1. The editor is the MCP host.
2. Its MCP client launches or connects to your server.
3. The server validates tool arguments and calls the PCB pipeline.
4. The pipeline invokes pinned versions of KiCad and your own scripts in a controlled project directory.

MCP uses JSON-RPC and supports local standard input/output as well as Streamable HTTP. stdio is the sensible first transport for a pipeline that reads local design files: the editor starts the server as a child process, no listening port is required, and credentials need not be passed to the model. A shared remote service needs authentication, per-project authorization, origin validation, audit logs, and tenant isolation.

MCP does not make a generated schematic correct. It makes specific evidence available to the model and lets the host mediate actions. The engineering controls still belong in the manufacturing gate.

Start with resources, then add narrow tools

Expose read-only facts as resources. Good examples are the project manifest, board constraints, approved parts list, latest ERC report, and a release manifest. A resource URI can make scope obvious:

pcb://projects/weather-node/constraints
pcb://projects/weather-node/reports/latest/drc
pcb://projects/weather-node/releases/r3/manifest

Use tools for computation or side effects. A practical first server needs only a few:

• run_erc(project, severity)
• run_drc(project, check_schematic_parity)
• summarize_board(project)
• export_review_package(project, revision)

Do not expose run_shell(command) or accept arbitrary file paths. Resolve a project ID through a server-owned allowlist, then reject paths that escape that root. Keep fabrication export separate from release approval: generating Gerbers is reversible; declaring them approved is a human decision.

A DRC tool schema can be deliberately boring:

{
  "name": "run_drc",
  "description": "Run KiCad PCB DRC and return a structured summary. Does not modify or release the design.",
  "inputSchema": {
    "type": "object",
    "properties": {
      "project": { "type": "string", "pattern": "^[a-z0-9-]+$" },
      "check_schematic_parity": { "type": "boolean", "default": true }
    },
    "required": ["project"],
    "additionalProperties": false
  }
}

Return machine-readable fields—tool version, design commit, counts by severity, report path, and pass/fail—plus a short text summary. Do not return a thousand-line report unless requested; make the full report a resource.

Wrap KiCad deterministically

Pin the KiCad major/minor version in the build environment and print it in every result. Command flags can change between releases, so test the wrapper against the exact version used in CI. For KiCad 9, a local gate might contain:

set -eu
mkdir -p build/reports

kicad-cli version
kicad-cli sch erc \
  --exit-code-violations \
  --output build/reports/erc.rpt \
  hardware/weather-node.kicad_sch

kicad-cli pcb drc \
  --exit-code-violations \
  --schematic-parity \
  --output build/reports/drc.rpt \
  hardware/weather-node.kicad_pcb

Run each command without a shell when implementing the server—for example, with an argument array passed to a subprocess API. That prevents a project name from becoming shell syntax. Set a timeout, cap captured output, use a fresh output directory, and treat a nonzero exit status as a tool result with diagnostics rather than an MCP transport failure.

For deeper automation, see headless KiCad with kicad-cli. If the design source itself is generated, keep the source-to-KiCad compiler before the same checks; code-native EDA changes how the board is authored, not what must be verified.

Connect the server to an editor

The exact settings key varies by MCP host, but a local configuration usually describes a command, arguments, environment, and working directory:

{
  "mcpServers": {
    "pcb-pipeline": {
      "command": "node",
      "args": ["tools/pcb-mcp/dist/server.js"],
      "env": {
        "PCB_PROJECTS_FILE": "config/pcb-projects.json"
      }
    }
  }
}

Never put supplier tokens or signing keys in a resource, tool description, repository file, or tool result. The MCP host or server process should hold secrets and apply them only after authorization. With stdio, log diagnostics to standard error; standard output is reserved for protocol messages.

Before enabling the server in an agent, test it with an MCP inspector. Confirm that malformed project IDs fail, symlink escapes fail, a KiCad timeout is reported cleanly, and two simultaneous requests cannot overwrite the same report.

Make releases a two-step operation

An agent can run checks and assemble evidence. It should not silently turn that evidence into a production order. A safe flow is:

inspect -> edit -> ERC/DRC -> export candidate -> human review -> sign manifest

The candidate package should record the Git commit, KiCad version, command configuration, file hashes, board stackup, and unresolved exclusions. Signing or promoting the manifest should require an explicit confirmation outside model-authored text. This matters because an ERC pass cannot confirm a connector is mirrored, and DRC cannot decide whether a regulator is thermally adequate—examples of the limits of AI in hardware.

MCP is valuable here because it turns an opaque conversation into calls with reviewable inputs and outputs. Keep the interface small, make every artifact traceable, and let deterministic checks—not the confidence of an answer—decide whether the pipeline advances.