Why AI agents cannot touch embedded hardware today
Embedded engineers have watched AI coding assistants eat software workflows whole. Autocompletion, code review, refactoring, incident analysis — all better than they were twelve months ago. But at the lab bench, nothing changed. The AI still lives in your editor. The hardware still lives on a shelf, behind a USB-SD-Mux, connected to a board that sometimes hangs in U-Boot.
So you keep alt-tabbing. Run a command, copy the serial output into the chat, paste the agent's reply back into the terminal, repeat. Every round trip is manual. Every context switch breaks flow. Every hour spent translating between the chat and the UART is an hour you are not shipping.
The Model Context Protocol (MCP) removes the translator. It is an open standard for giving AI agents structured access to external tools — including tools that speak to real hardware. Plug one MCP server into your AI client and the agent calls those tools directly: it reads the results, reasons about them, and decides what to do next. No scripts, no copy-paste, no prompt gymnastics.
This guide walks through what MCP is, how to wire an AI agent to real embedded boards in about five minutes, what a real hardware-in-the-loop session looks like, what to worry about from a safety and security standpoint, and where the workflow is heading.
Who this guide is for
If you recognise yourself in any of these, keep reading — the rest of the post is written for you:
Embedded Linux & BSP engineers
You spend half the day between an editor, a terminal, and a bench. MCP removes the bench trip for anything that does not need a scope or a soldering iron.
Test and QA leads
You want hardware-in-the-loop tests that read like English and produce audit-ready output, without writing a custom framework first.
CI and DevOps engineers
You are tired of maintaining Bash that power-cycles boards and greps UARTs. An MCP-enabled agent can do the same job from a natural-language spec, with its own retry logic.
AI tool builders
You are evaluating MCP and want a concrete, real-hardware example of a production MCP server. This post walks one end-to-end.
What is the Model Context Protocol (MCP)?
MCP is an open standard that defines how AI agents discover and call external tools. Think of it as a universal adapter for AI: one MCP server publishes a set of tools, and any MCP-compatible client can use them — Claude Code, Cursor, Windsurf, VS Code extensions, or a custom agent you build yourself. Write the server once; every compatible agent, now and in the future, can use it.
When an agent starts, it connects to each configured MCP server, asks for the tool list, and reads the descriptions. Those descriptions teach it what it can do — list devices, acquire leases, send console commands, flash images — and how to call each tool. The agent then calls those tools on its own, in the order it judges correct, just like it calls code search or a file editor.
That shifts the interaction model. Instead of copy-pasting terminal output into a chat window, the agent reaches into your world directly, reads results, and decides what to do next. That is the capability the rest of this post depends on.
How to set up an MCP server for hardware control
To give your AI agent hardware access through MCP, you need three things: a
board, an MCP server that exposes tools for it, and an MCP-compatible client.
fernctl ships the server built-in, so the setup is two commands.
First, configure fernctl with your fernsteuerung.io credentials:
fernctl config --server https://fernsteuerung.io --token your-api-tokenThen add fernctl as an MCP server in your AI client's config. In
Claude Code, add this to .mcp.json:
{
"mcpServers": {
"fernctl": {
"command": "fernctl",
"args": ["mcp"]
}
}
}The same config works for any MCP-compatible client — Cursor, Windsurf, or a custom agent. Restart the client and it discovers all 16 hardware-control tools automatically. No SDK, no plugin, no integration code.
MCP + Claude Code demo: driving a real embedded Linux board
The clip below is a real session: Claude Code, the fernctl MCP
server, and a physical phyBOARD-Electra AM64x. Every tool call was made
autonomously by the model. No scripting. No manual intervention between
prompts.
fernctl over MCP.
Try this on your own board
A fernsteuerung.io account is free. If you already have a USB-SD-Mux, a power switch, and a serial adapter, you can reproduce the session above in under ten minutes.
Create a free account See the setup guideThe transcripts below are from the same session, shown step by step so you can see exactly which tools the agent chose and why.
“What devices are available?”
The simplest query. One tool call, one formatted device overview out:
❯ What devices are available?
● fernctl - list_devices (MCP)
● There are 2 devices available, both currently online and not leased:
NAME STATUS LEASED?
phyBOARD-Electra-AM64x Online No
phyBOARD-Segin-STM32MP13x-2 Online NoThe agent already knows your fleet. No scripting, no filters, no paging.
“Update the RTC of the Electra to use the current date”
This is where MCP earns its keep. A task that normally takes several manual steps — the agent handles the entire workflow on its own:
❯ Update the RTC of the Electra to use the current date
● fernctl - lease_acquire (MCP)
➜ Lease acquired (expires in 10 minutes)
● fernctl - device_power (MCP) action: "on"
➜ Power on sent
● fernctl - console_connect (MCP)
➜ Connected. Session ID: 1cc3b840-...
● fernctl - console_login (MCP)
➜ Login successful
● fernctl - console_send (MCP)
➜ date -s "2026-03-29 13:45:00" && hwclock -w && hwclock -r
● fernctl - console_disconnect (MCP)
● fernctl - lease_release (MCP)
● Done. The Electra's RTC is now set to 2026-03-29.
System clock updated with date -s, synced to hardware clock with hwclock -w.One sentence in. Eight tool calls later: lease acquired, board powered up, console connected, login completed, commands run, output read, console disconnected, lease released. The agent even picked the right Linux commands for the job.
“Flash the container image to the Electra”
Remember the bitbake-to-board workflow? Upload, lease, flash, release. With MCP, the agent does all of it from a single sentence:
❯ Flash the container image to the Electra
● fernctl - lease_acquire (MCP) ttl_minutes: 30
➜ Lease acquired (expires in 30 minutes)
● fernctl - flash_device (MCP)
image: phytec-container-image-phyboard-electra-am64xx-2.rootfs.wic.xz
bmap: phytec-container-image-phyboard-electra-am64xx-2.rootfs.wic.bmap
➜ Flash complete
● fernctl - lease_release (MCP)
● Done. The container image has been flashed to the Electra successfully.The agent matched the right image and its bmap from the image hub, requested a longer lease because flashing takes minutes, and released it when done. A multi-step CLI workflow collapsed to a conversation.
“Check if podman is available and ready to use”
After flashing, verify something on the running system. Same pattern, shorter prompt:
❯ Check if podman is available and ready to use
● fernctl - lease_acquire (MCP)
● fernctl - device_power (MCP) action: "on"
● fernctl - console_connect (MCP)
● fernctl - console_login (MCP)
● fernctl - console_send (MCP)
➜ podman --version && podman info --format '...' && podman ps -a
● fernctl - console_disconnect (MCP)
● fernctl - lease_release (MCP)
● Podman is ready to go on the Electra:
- Version: 5.0.2-dev
- OCI Runtime: crun
- Running containers: none (clean slate)The full lifecycle again — lease, power, console, login, command, cleanup — with the agent summarising results in plain English.
MCP tools exposed by fernctl
fernctl mcp publishes tools covering the full device lifecycle.
The agent discovers all of them automatically, reads their descriptions, and
chooses which ones to call based on your prompt.
Device management
list_devices— discover registered boards with status and lease infodevice_power— power on, off, or reset a board
Lease management
lease_acquire— get exclusive access with a TTL (1–240 minutes)lease_release— give up access when donelease_show— check who holds the lease
Serial console
console_connect/console_disconnect— open and close a persistent serial sessionconsole_send— send text input to the consoleconsole_login— auto-login, handling boot output gracefullyconsole_exec— run a command and capture the output with exit codeconsole_wait_for— wait for a regex pattern in console output (useful for boot detection)
Images and flashing
list_images— browse available firmware images with filteringupload_image— push a new image to the hubflash_device— flash an image to a board (blocks until complete)
You never have to teach the agent the workflow. It reads the tool definitions, sees which parameters each one takes, and composes them into the right sequence for your request.
Is it safe to let AI agents control real hardware?
A fair question — and one worth answering before handing a model a flash command. Short version: you can make this safe with the defaults fernctl ships with, and much safer with a small amount of discipline. Here is what protects you, and where you should still be careful.
Leases are TTL-bounded, so an agent cannot hold a board forever
Every lease_acquire call takes a TTL between 1 and 240
minutes. The platform releases the lease automatically when the TTL
expires, even if the agent crashes, loses context, or leaves a session
hanging. The board stays recoverable.
The MCP server runs on your machine
When you run fernctl mcp, the MCP server is a local process
on your laptop. The model-to-tool conversation stays local. Tool calls
then hit fernsteuerung.io over HTTPS using your existing API token
— the same data path as a manual fernctl call. No
new network exposure.
Every tool call is audited
Calls go through your user identity, so the dashboard shows which leases were acquired, which images flashed, and when — useful for tracing what an agent actually did during a long session.
You still control which boards the agent can see
A token is scoped to your account. If you do not want an agent touching production hardware, give it a token that only has access to a staging board or a dedicated MCP testbed.
flash_device. Once you trust the session shape, widen access. This
is the same workflow hygiene that makes AI-assisted coding safe — the same
instincts apply.
AI-driven embedded testing use cases
Once an agent can touch real hardware, the interesting workflows are the ones that used to require custom glue code. Each of the patterns below is deep enough to be its own post; this section is a map of where the workflow is heading.
Hardware-in-the-loop tests written in plain English
Describe a test the way you would brief a colleague: “Boot the
board, verify eth0 gets a DHCP address, check the custom
systemd service starts within 30 seconds, and confirm the GPIO expander
responds on I2C bus 2.” The agent translates that intent into
console commands, reads the output, and reports pass or fail. No pytest
fixtures, no harness, no boilerplate — just a prompt that says
what “working” means on hardware.
Auto-debug CI failures on real boards
CI catches a boot failure. Instead of SSHing to the lab and reproducing it by hand, feed the serial log to an agent with MCP access. It can flash the suspected image, bisect across earlier builds in the image hub, read kernel messages, correlate with known regressions, and suggest a fix. Reading logs is passive; an MCP-connected agent can interact with the failing system, test hypotheses, and narrow down the root cause.
From bitbake to board and back — one prompt
The full feedback loop driven by a single prompt: build a Yocto image, upload it, flash a board, run validation, find a regression, trace it to a recipe change, patch the recipe, rebuild, and re-test — all without you switching windows. The gap between “I changed a recipe” and “I know it works on hardware” collapses to a conversation.
Multi-board orchestration
“Flash all three AM64x boards with the latest nightly and run the network stress test on each.” The agent manages leases across devices, flashes images, runs the tests in parallel where it can, collects results, and produces a comparison — without you touching a single board.
AI-assisted BSP porting
Porting a BSP to a new board variant means iterating on device-tree changes, rebuilding, flashing, and watching the boot log — over and over. With MCP access, the agent can try device-tree tweaks, flash the updated image, observe the boot output, identify what failed, and try again. A days-long manual process becomes an interactive session.
Context-aware log analysis
The agent reads a kernel panic from the serial console, cross-references it with the kernel source and device-tree bindings, and explains what went wrong in context — not as a generic answer. It knows which board it is running on, what image was flashed, and what commands led to the failure. That context turns diagnosis into an actionable next step.
Frequently asked questions
Can Claude, Cursor, or ChatGPT really control physical hardware?
Yes — with the Model Context Protocol. Any MCP-compatible
agent can call real tools, including ones that touch hardware.
fernctl ships a built-in MCP server that exposes 16
hardware-control tools (power, serial console, flashing, leases) to any
MCP client like Claude Code, Cursor, or Windsurf.
What is the Model Context Protocol (MCP)?
MCP is an open standard introduced in late 2024 that defines how AI agents discover and call external tools. Think of it as a universal adapter: one MCP server publishes a set of tools, and any MCP-compatible client can use them without a custom integration. See modelcontextprotocol.io for the spec.
How is an MCP server different from a custom tool plugin?
Custom plugins bind to a single AI product. An MCP server works with every MCP-compatible client — write it once, and it works in Claude Code, Cursor, Windsurf, VS Code extensions, and any future agent that speaks MCP. No vendor lock-in, one integration effort.
Is it safe to give an AI agent access to embedded hardware?
It can be, with guardrails. Every fernctl MCP tool call runs under a TTL-bounded lease (1–240 minutes), so an agent cannot hold a board indefinitely. The MCP server runs locally on your machine, auth uses your fernctl API token, and every call is audited on fernsteuerung.io. Start with a dedicated staging board and short leases, then widen access as you build confidence — the same posture that makes AI-assisted coding safe.
Does fernctl's MCP server work with models other than Claude?
Yes. MCP is an open standard, so any MCP-compatible client
works — Claude Code, Cursor, Windsurf, plus a growing list of IDE
extensions and custom agents. The same .mcp.json entry works
across all of them.
Do I need to write any code to expose my boards to an AI agent?
No. Run fernctl mcp and add a single entry to
your AI client's MCP config. The server advertises all 16 hardware-control
tools automatically. The agent reads the tool descriptions, infers
parameters, and calls them in the right order — no wrapper scripts
or prompt engineering required.
Does this work for hardware-in-the-loop (HIL) CI pipelines?
Yes. The same fernctl binary powers both the CLI
and the MCP server, so an AI agent can drive HIL workflows that previously
needed Bash or pytest fixtures: acquire a lease, flash an image, wait for
boot, run a validation command, release the lease. Natural-language test
specs become executable HIL tests. See the
bitbake-to-board
guide for the CLI equivalent.
How much does it cost to use AI agents with embedded hardware?
fernsteuerung.io has a free tier you can register for without a credit card. Your AI client's token usage is billed separately by whichever model provider you use. A typical hardware task (flash plus verify) uses a handful of tool calls and fits comfortably inside a free-tier chat session.
Get started in 5 minutes
MCP turns fernsteuerung.io from a remote hardware platform into an
AI-accessible hardware platform. If you already use fernctl,
adding MCP is one config entry. If you are new, you can connect your first
board in about ten minutes.
No credit card. Free tier included.