MCP as the Integration Layer for Hardware Developer Tools

Engineers testing an electronics prototype with a laptop and lab instruments on a workbench Photo by ThisIsEngineering / Pexels

A DVT failure that actually matters never lives in one tool. The 1.2 V rail droops under load. The OpenHTF record blames a single test phase. The latest PCB revision moved the sense resistor. The ECO is still sitting in PLM. An experienced engineer can walk that chain because they already know where the schematic, the test result, and the scope capture live.

An AI agent cannot, unless each system gives it a stable way to ask for data and perform bounded actions.

That is the job of the Model Context Protocol (MCP). It is not another model, dashboard, or agent framework. It is the contract between the reasoning layer and the tools that hold engineering truth: ECAD, embedded toolchains, test benches, PLM, and MES.

Key Takeaways

MCP's July 2026 spec is production plumbing: stateless HTTP, Tasks for long-running bench jobs, and MRTR for mid-call human approval (MCP Blog, 2026-07-28).

Official Tier 1 SDKs now see close to 500 million downloads a month, with TypeScript and Python each past 1 billion total downloads (MCP Blog, 2026-07-28).

Anthropic's Model Hardware Standard (research preview, Aug 27, 2026) sits under MCP for physical devices. Carnegie Mellon wired four instruments in eight hours instead of weeks.

Only about one in five large discrete manufacturers has mature PLM-MES integration; over three-quarters still look up change impact by hand (Tech-Clarity, 2026).

Hardware agents need four adapters, not one mega-server: ECAD, deterministic test/firmware execution, physical devices, and PLM/MES.

The Integration Tax Is the Real Bottleneck

Most hardware agents start as a convincing demo. A model reads a PDF, summarizes a log, and recommends a next step. The demo dies at the first system boundary.

The schematic lives in KiCad. Firmware artifacts live in a build cache. Test sequencing lives in OpenHTF. Measurements come from vendor instrument libraries. The engineering BOM lives in PLM. The manufacturing BOM lives in MES. Each connection has different auth, data shapes, and failure modes.

Without a shared protocol, every agent-to-tool pair becomes custom glue: one wrapper per model and ECAD API, another for the test executive, a third when the team switches agent hosts, then more translation when a tool renames an operation.

That is an N-by-M integration problem. MCP changes the boundary. Tools expose capabilities once as servers. Agent hosts consume the same protocol. The model can change without rewriting the instrument adapter.

The ecosystem signal is no longer theoretical. Anthropic donated MCP to the Agentic AI Foundation under the Linux Foundation on December 9, 2025, citing 97 million-plus monthly SDK downloads. The AAIF launch cited more than 10,000 published MCP servers. Eight months later, the 2026-07-28 specification reported close to half a billion monthly downloads across Tier 1 SDKs. A lab integration should outlive whichever model is fashionable this quarter.

The plant-side data is equally blunt. Tech-Clarity's survey of 200-plus complex discrete manufacturers with both PLM and MES found that only about one in five has mature, synchronized integration. Over three-quarters still look up engineering-change impact by hand (Integrating PLM with MES, 2026). A Kalypso write-up of the same study found 91% of those manufacturers calling PLM-MES integration at least important, and 57% calling it critical, while 80% still rely on manual lookups to keep change data in sync (Kalypso, 2026). Microsoft's July 2025 Signals report found 31% of design-and-engineering respondents calling BOM misalignment across PLM, ERP, and MES a significant issue (Signals Report).

Agents cannot close a hardware loop on top of that mess unless the glue is a contract, not a one-off script.

What MCP Standardizes in 2026

The 2026-07-28 MCP specification still uses JSON-RPC 2.0. Hosts talk to clients. Clients talk to servers. Servers advertise three primitives:

Resources: Readable context such as a board revision, calibration record, or test result
Tools: Callable operations such as running DRC, fetching a waveform, or starting an approved test profile
Prompts: Reusable workflow templates such as a failure-triage checklist

For hardware, that split is the point. Reading a DRC report is not the same risk as changing a footprint. Listing completed test records is not the same risk as energizing a rail. The server describes those operations separately. The host decides what the agent may invoke.

The July 2026 revision also fixed three problems that used to make lab MCP servers feel toy-grade:

Stateless requests. There is no protocol-level session to pin to one process. Each call carries identity and capabilities. If your bench job needs continuity, the server returns an explicit handle (run_id, capture_id) and the model passes it back. That is how you should have designed test orchestration anyway.

Tasks. Long-running work moved into the official Tasks extension. A 40-minute HIL sweep should return a task handle, not hold an HTTP stream open. The client polls tasks/get until the deterministic executor finishes.

MRTR (multi round-trip requests). A tool can pause and ask for missing input or a human confirmation, then retry with the answers attached. That is the right primitive for "apply 12 V to channel 2?" It is not a prompt. It is a protocol-level approval gate.

Authorization still lives with you. OAuth answers "who connected?" It does not answer "should this voltage be applied?" That policy belongs inside the server closest to the device.

Close-up of a motherboard showing chips, traces, and solder joints Photo by Athena / Pexels

Four Adapters, Not One Mega-Server

The cleanest architecture does not hide every system behind one "hardware" server. It uses focused servers with narrow ownership and permissions.

Adapter 1: ECAD context through KiCad

KiCad 9, released in February 2025, introduced an official IPC API as a stable, language-agnostic interface to a running KiCad process. The first release concentrated on the PCB editor. The useful idea was already there: stop scraping the GUI, speak a versioned API.

That API is a credible foundation for an MCP server. Community projects such as KiCad MCP Pro and KiCAD-MCP-Server expose board inspection, net tracing, ERC/DRC, and manufacturing export as agent tools. They are not official KiCad features. Pin a version, inspect the schemas, and test them against boards you actually ship.

A practical ECAD server starts read-heavy:

get_board_revision()
trace_net(net_name)
list_components(reference_prefix)
run_drc()
export_bom()

Keep move_footprint() and update_track() behind explicit approval until the read path is trustworthy.

Adapter 2: Deterministic test and firmware execution

OpenHTF already solves a different problem well. It provides test phases, measurements, result records, and plugs that manage hardware initialization and cleanup. It is the deterministic executor, not the reasoning layer.

There is no native OpenHTF MCP server in the official project. The integration pattern is to wrap existing test plans and plug-backed capabilities behind a small MCP service:

list_test_profiles(dut_family)
get_test_record(serial_number, run_id)
queue_test(profile, serial_number)
get_phase_measurements(run_id, phase)
abort_test(run_id, reason)

The agent chooses a valid profile and interprets structured results. OpenHTF still owns limits, sequencing, teardown, and pass/fail. That boundary stops an LLM from inventing a test phase or bypassing a safety interlock.

TesterKit (v0.4.0, July 2026) is a packaged version of the same idea: record OpenHTF or pytest runs, then expose them over testerkit mcp serve. Firmware flashing belongs here too, as a gated tool with an explicit device ID and image hash. Do not give the model raw openocd on stdin.

Adapter 3: Physical devices through a gateway

Bench equipment is where abstractions meet voltage, heat, and motion. A gateway such as Jeltz maps serial, MQTT, USB, or HTTP-connected devices into one MCP endpoint. You write a TOML profile describing commands, or flash self-describing firmware. The daemon can record readings to SQLite while serving tools over Streamable HTTP.

On August 27, 2026, Anthropic opened a research preview of the Model Hardware Standard (MHS): a driver layer with read/write primitives, a generated capability-and-limits file per device, and three control paths including MCP. Carnegie Mellon used it to run a four-instrument workflow across three computers with incompatible interfaces in eight hours, versus the weeks a vendor-built integration typically takes (Anthropic, 2026). Treat MHS as an emerging device contract, not a package you can pin this weekend. The architecture lesson is already usable: discoverability, typed commands, and safety limits enforced at the driver, not in the prompt. Jeltz and a small custom gateway are how you apply that lesson on an electronics bench today.

That pattern is useful even if you build the gateway yourself. Normalize device identities. Expose typed commands. Return units with every measurement. Do not hand a model raw serial access and hope the prompt provides safety.

A power-supply tool should look like this:

@server.tool()
def set_rail(channel: int, volts: float, current_limit_a: float, duration_s: int) -> dict:
    """Set a PSU rail inside the instrument envelope. Duration is required."""
    if channel not in ALLOWED_CHANNELS:
        raise ValueError("channel not in allowlist")
    if volts > MAX_VOLTS[channel] or current_limit_a > MAX_AMPS[channel]:
        raise ValueError("requested setpoint exceeds envelope")
    apply_setpoint(channel, volts, current_limit_a, duration_s)
    return {"channel": channel, "volts": volts, "status": "armed"}

The schema is the safety rail. The LLM fills arguments. The server rejects anything physically illegal.

Adapter 4: PLM and MES as governed tools

This is the adapter most hardware-agent demos skip, and it is why those demos never survive an ECO.

You do not need a vendor-native "Teamcenter MCP" on day one. You need thin tools over APIs you already trust:

get_ebom(part_number, revision)
get_eco_status(change_id)
list_affected_test_plans(change_id)
get_mbom_delta(ebom_rev, plant)
get_work_order(serial_number) (read-only from MES)

SAP now documents this exact pattern. The MCP Gateway in SAP Integration Suite (updated May 2026) turns SAP and non-SAP APIs into governed MCP tools with OIDC, rate limits, and observability. Data stays in the system of record.

Siemens' Fuse EDA AI Agent (March 2026) makes the same bet on the design side: dynamic discovery across MCP-connected EDA tools, plus domain guardrails. You do not need that stack to steal the architecture. Standard tool boundary, plus validation that belongs to the domain.

The Closed Loop in Practice

Laptop screen showing source code for tool integration and agent orchestration Photo by Luis Gomes / Pexels

With those adapters, the original rail-droop investigation becomes a reviewable sequence:

Engineer: Investigate the new 1.2 V load-step failures on Rev C.

Agent -> Test server:
  list recent failing runs for Rev C

Agent -> Test server:
  read phase measurements and artifact references

Agent -> ECAD server:
  trace 1V2_SENSE and compare Rev B with Rev C

Agent -> PLM server:
  fetch the ECO that landed the sense-resistor move

Agent -> Device gateway:
  read the stored scope capture and PSU telemetry

Agent:
  propose a targeted rerun with evidence and expected limits

Engineer:
  approve the rerun (MRTR confirmation)

Agent -> Test server:
  queue the approved OpenHTF profile as a Task

The model reasons across systems. It never owns the test sequence or the instrument driver. Each tool returns structured evidence. Each state-changing call is attributable. The engineer approves the expensive action.

Security Must Live at the Tool Boundary

MCP makes tools discoverable, which also makes tool metadata part of the attack surface. Hosts should treat tool descriptions as untrusted unless the server is on an allowlist.

The 2025 MCPTox benchmark tested 353 tools from 45 live MCP servers across 1,312 malicious cases. The most vulnerable evaluated configuration reached a 72.8% tool-poisoning attack success rate. The highest refusal rate among tested agents was below 3%.

For hardware, the defensive pattern is boring and sufficient: allowlist and pin servers, separate read tools from state-changing tools, validate parameters against physical limits, require human approval for energizing or flashing, and log every invocation with arguments and model identity. Return immutable artifact references so another engineer can reproduce the conclusion.

If a tool can apply voltage, the server closest to the PSU is the policy engine. The LLM is not.

A Weekend-Sized Starting Point

Do not begin by connecting the entire lab. Pick one failure loop with painful context switching and a safe read path.

First, expose evidence. Wrap OpenHTF records or TesterKit results. Return typed fields, stable run identifiers, units, timestamps, and links to raw captures.

Second, add one engineering context source. A read-only KiCad tool that traces a named net or runs DRC is enough to prove cross-system reasoning.

Third, add one governed enterprise read. get_eco_status() or get_ebom() beats another dashboard widget. It is also the fastest way to find out your part numbers do not mean the same thing in two systems.

Fourth, add one gated action. Let the agent queue an existing test profile only after a human confirms the DUT, fixture, and limits. Use Tasks for the wait. Keep the deterministic executor in charge.

Measure three things: investigation time, number of manual system hops, and the percentage of agent claims backed by retrievable artifacts. "The agent sounded helpful" is not an operations metric.

MCP will not clean inconsistent board names, repair stale calibration data, or decide which actions deserve approval. It gives those problems a stable boundary. Boundaries are where hardware teams can add schemas, ownership, tests, and policy.

The architecture that survives contact with a lab is simple: agents plan, MCP connects, deterministic systems execute, and engineers approve irreversible work.

Next in this series: the modern embedded developer toolchain, from SDK to hardware-in-the-loop.