AI on the RF bench: building the eng-mcp-suite

“AI is going to change engineering” is easy to say and hard to cash. The interesting question isn’t which model — it’s what the model can actually touch.

An LLM on its own can talk about an antenna; it can’t sweep one. The leap from chatbot to lab assistant is tools — concrete, typed actions the model can call: configure a VNA sweep, look up an FCC limit, SSH into a device under test, render a radiation pattern. Model Context Protocol (MCP) is the standard that makes those tools pluggable, and it’s where I’ve spent a lot of my “AI in RF” effort.

One at a time, then a suite

I kept building these servers one at a time — a VNA control server, an EMC-limits server, an SSH/serial server for the embedded bench, the MCP side of RFlect for antenna analysis. At some point it stopped being a pile of repos and became a stack.

eng-mcp-suite is the result: a single installer that brings up a Claude Desktop / Claude Code environment with more than a dozen engineering MCP servers — pre-configured, namespaced, and grouped by workflow. It spans:

• Transmission lines & EM — closed-form line solving, openEMS FDTD, NEC2, CST Studio
• PCB / SI — layout review, return paths, decoupling, DDR / PCIe / USB signal integrity
• Circuit — LTspice + Qucs-S + scikit-rf, all Touchstone-aware
• EMC — FCC / CISPR / IEC / ISO limit lookup
• Lab test — VNA, spectrum analyzers, signal generators, comms testers
• Glue — SSH / serial to DUTs, draw.io engineering diagrams, 3D modeling

Layers of one stack

The point isn’t a dozen disconnected tools — it’s that they’re layers of the same RF design loop, and an agent can move between them:

        AI agent (Claude Code / Desktop)
               │  via MCP
   closed-form / analysis        ← fast inner loop
               │  Touchstone (.s2p)
   3D EM  (openEMS / NEC2 / CST)  ← full-wave validation, where closed-form runs out
               │
   circuit  (LTspice / Qucs-S)    ← system-level integration
               │
   lab hardware (VNA / SA / sig-gen) ← physical measurement closes the loop

Ask for an impedance match and the agent can solve it closed-form, validate it in 3D EM where the approximation runs out, and — if the gear is connected — measure it on a real VNA, all in one conversation. The handoffs between layers are just files (Touchstone .s2p) and tool calls.

Workflow bundles

You rarely want all of it at once, so the suite ships curated bundles for common tasks:

eng-mcp-suite install --workflow rf-design       # lines + EM + circuit + EMC bands
eng-mcp-suite install --workflow emc-compliance   # EMC limits + diagrams + remote access
eng-mcp-suite install --workflow lab-automation   # VNA + spectrum + sig-gen + DUT access

Each bundle wires exactly the servers that workflow needs into one merged config — no hand-editing claude_desktop_config.json.

Where it helps — and where it doesn’t

I’ll be honest about the line. Where an agent on the bench genuinely earns its keep:

• Repetitive setup — sweeps, recalls, exports, file wrangling.
• Lookups and cross-referencing — “FCC Part 15 Class B at 100 MHz vs. CISPR 32,” in seconds, cited.
• First-draft analysis — “which intermod products land in my victim band,” then refine.

Where it doesn’t, and shouldn’t:

• It doesn’t decide whether a result is physical. A clean-looking number from a bad setup is still wrong, and knowing the difference is the job.
• It doesn’t own design intent. The agent is a fast, tireless technician — not the engineer.

That’s exactly why every server in the suite follows the same rule RFlect does: the tools compute deterministically and the agent narrates. The math never depends on the model, so the numbers stay trustworthy even when the prose is wrong.

Try it

I wrote up one member of the suite in depth in Building RFlect; the rest are on GitHub. If you’re an RF or EMC engineer curious about putting an agent on your bench, the suite is the fastest way I know to try it — and a good place to contribute if you want your own instrument on the list.