MCP Explained: Model Context Protocol for AI Assistants, Local Tools, and Embedded Work

MCP (Model Context Protocol) is an open protocol that lets an AI assistant call tools and read data from programs you run. The model stays in the chat app. The MCP server is a local (or remote) process that exposes tools such as “read this folder”, “query this database”, or “run this command”.

It is not a neural-network format, not a Linux kernel interface, and not something you flash onto a microcontroller. Think of it as a USB-C for AI tools: one way for Cursor, Claude Desktop, and similar hosts to talk to many servers.

The pieces

A server typically exposes:

• Tools — actions the model can call (list_serial_ports, read_file)
• Resources — readable data (file://, a log, a datasheet)
• Prompts — reusable prompt templates the host can offer

The host decides what the model is allowed to call. You still approve risky actions.

When MCP is worth using

Use MCP when the assistant needs repeatable access to something outside the current chat:

• A local folder of datasheets, schematics, or Yocto recipes
• Git, issue trackers, or a company wiki
• A database, browser, or build log
• A thin wrapper around a CLI you already trust (west, openocd, bitbake -e)

Skip MCP when:

• The file is already in the open workspace and a normal chat is enough
• You only need a one-off copy-paste from a terminal
• The action is dangerous and you would not let a script run it unattended (raw dd, production flashing)

MCP shines for the same tool, many times, not for a single question.

How you actually use it

1. Install a host that supports MCP.
2. Add a server config (command + args, or a URL).
3. Restart the host so it starts the server.
4. Ask in natural language. The model picks a tool if the server advertised it.

A local server is just a program. The host launches it and talks JSON-RPC on stdin/stdout.

Claude Desktop uses claude_desktop_config.json. Cursor uses MCP server settings (often an mcp.json in the project or user config). The idea is the same: name, command, arguments, optional environment variables.

Local example: give the AI a datasheet folder

This uses the official filesystem server. Point it at a directory you care about, not your entire home folder.

{
  "mcpServers": {
    "datasheets": {
      "command": "npx",
      "args": [
        "-y",
        "@modelcontextprotocol/server-filesystem",
        "/home/you/docs/silicon"
      ]
    }
  }
}

After the host loads it, you can ask: “From the i.MX 8M Plus datasheet, what DRAM types are listed?” The model uses the filesystem tools instead of guessing.

A Git-aware server is the same pattern: command plus a repo path. Keep the root directory small. MCP does not make a tool safe; it only makes it callable.

Local example: a tiny custom server

Official servers cover files, Git, and browsers. Embedded work often needs your CLI. Below is a minimal Python sketch using the MCP SDK: one tool that lists USB serial devices.

from mcp.server.fastmcp import FastMCP
import glob

mcp = FastMCP("board-tools")

@mcp.tool()
def list_serial_ports() -> list[str]:
    """List USB serial device nodes on this Linux PC."""
    return sorted(glob.glob("/dev/ttyUSB*") + glob.glob("/dev/ttyACM*"))

if __name__ == "__main__":
    mcp.run()

Register it:

{
  "mcpServers": {
    "board-tools": {
      "command": "python3",
      "args": ["/home/you/mcp/board_tools.py"]
    }
  }
}

Then: “What serial ports are on this machine?” You can add tools later (read_uart, run_openocd_halt) the same way. Start read-only. Flashing and openocd -c "reset halt" belong behind explicit tool names and human approval.

MCP and the embedded world

MCP does not replace UART, CAN, RPMsg, MQTT, or GDB on the device. The protocol lives on the engineering PC (or a lab server), next to the AI host.

Useful embedded patterns:

What not to do:

• Do not expect an STM32 or a Yocto image to “run MCP” as firmware.
• Do not expose a production device’s root shell to an MCP tool on the public internet.
• Do not let a tool run arbitrary shell strings. Wrap named operations with fixed arguments.

MCP is closer to a plugin API for the assistant than to a fieldbus. The embedded value is faster lookup and safer, repeatable lab commands—not a new on-device protocol.

Practical rules

• Prefer stdio + local process for secrets and hardware. Use remote HTTP MCP only when you trust the network and the server.
• Constrain filesystem roots. A datasheet folder is useful; $HOME is a leak.
• Log or require confirmation for write/flash tools.
• Keep tools small and named after the real action. flash_probe is better than run_shell.
• If the host already has the repo open, you may not need MCP for that repo.

Quick decision guide

• Question about code already in the editor: skip MCP.
• Same PDFs, logs, or wiki, every week: filesystem or docs MCP server.
• Repeatable lab step (list ports, read a temperature sysfs node, run a fixed OpenOCD script): small custom server.
• Need the MCU to talk to Linux on the board: use UART, RPMsg, or MQTT—not MCP.

Bottom line

MCP is how an AI assistant uses your tools through a standard interface.

• The host is Cursor or Claude; the server is a local program.
• Use it for repeated access to files, Git, databases, and wrapped CLIs.
• A local filesystem server is the fastest useful setup.
• In embedded work, MCP sits on the development PC. It can wrap datasheets, Yocto trees, serial ports, and debug probes. It does not run on the Cortex-M.

Start with one read-only server on a narrow directory. Add hardware tools only after the command is something you would put in a Makefile.