Arduino MCP Server

arduino-mcp-server

[npm version] [License: MIT] [Node.js 20+]

Give your AI assistant full control over Arduino — compile, upload, monitor serial, and verify wiring safety, all through natural language.

Part of the HardwareMCP ecosystem — open-source MCP servers that bridge AI to physical hardware.

What this does

AI assistants can control Jira, GitHub, and databases. They can't talk to a microcontroller — until now.

arduino-mcp-server wraps arduino-cli into an MCP server so your AI can:

• Detect connected boards and ports automatically
• Compile and upload sketches without touching the terminal
• Monitor serial output with stateful sessions (open, read, expect, write, close)
• Run electrical safety checks before sending commands to hardware
• Manage dependencies — cores, libraries, and CLI installation

Quick Start

Install:

npm install -g arduino-mcp-server

Add to Claude Desktop (claude_desktop_config.json):

{  "mcpServers": {    "arduino": {      "command": "npx",      "args": ["-y", "arduino-mcp-server"],      "env": {        "ARDUINO_CLI_PATH": "arduino-cli",        "ARDUINO_SKETCH_ROOT": "/path/to/your/sketches"      }    }  }}

Requires arduino-cli on your PATH, or let the server install it for you.

What you can say

Bootstrap from scratch:

"Check if Arduino CLI is installed and set everything up for an Arduino Uno."

Compile and upload:

"Compile my Blink sketch and upload it to the Uno on COM6."

Serial monitoring:

"Open serial on COM6 at 115200 and wait until the device prints READY."

Safety-first workflows:

"Run a safety preflight for an Arduino Uno with 5V on pin 13 at 25mA before I send commands."

Tools

Resources:

• arduino://boards/reference — structured board pin/capability reference

Prompts:

• arduino-cli-bootstrap-policy — policy for arduino-cli setup behavior
• arduino-setup-assistant — guided Arduino environment setup

Safety preflight guardrails

safety_preflight (and the safetyContext passed to upload_sketch, upload_and_wait_ready, and serial_write) now also covers battery and ESP32-family pin footguns, driven by small, extensible data tables rather than hardcoded to any one board:

Battery charge-rate (C-rate) check — pass a battery object (capacityMah, chargeCurrentMa, chemistry) and the check computes chargeCurrentMa / batteryCapacityMah and flags it:

• BATTERY_CRATE_UNSAFE (hard, blocking) above 1C
• BATTERY_CRATE_CAUTION (soft, non-blocking) above 0.5C

Generic small LiPo cells are commonly rated for roughly a 0.5–1C safe charge current, so the message spells out the math, e.g. "380mA into a 100mAh cell is a 3.8C rate — well above the ~0.5-1C safe range for typical small LiPo cells; verify your cell's actual rated charge current before proceeding." If chargeCurrentMa is omitted, it's inferred from a small board → onboard-charge-IC lookup table (currently seeded with Seeed XIAO ESP32S3, XIAO ESP32S3 Sense, and XIAO ESP32C3 — see data/battery-charge-ic-reference.json, easy to extend with more boards). These are approximate, manufacturer-published figures — verify against the live datasheet/wiki for your exact board revision before trusting them in a production workflow.

Battery polarity confirmation — when battery.connecting: true (or any battery field is set) but battery.polarityConfirmed isn't explicitly true, the preflight blocks with BATTERY_POLARITY_UNCONFIRMED and a reminder to never assume BAT+/BAT- from wire color. On Seeed XIAO boards it cites the official convention: the negative pad is closest to the USB-C port, positive is farthest from it.

ESP32-family pin safety (table-driven per board via data/board-reference.json):

• SPI-flash pins (GPIO6-11 on classic ESP32 WROOM/WROVER modules) — hard error (SPI_FLASH_PIN_USED); wiring these prevents boot.
• Boot-strapping pins (GPIO0/2/12/15 on classic ESP32) — caution; usable at runtime but risky if externally held during boot/reset (existing check).
• Input-only pins with no internal pull resistor (GPIO34-39 on classic ESP32) — caution (NO_INTERNAL_PULL_PIN); add an external pull-up/pull-down if using them as buttons/switches.
• Seeed XIAO ESP32S3 — modeled with its 11 usable GPIO (D0-D10), default I2C on D4/D5, and an informational note surfaced whenever D6/D7 are wired: they're hardware UART1 TX/RX by default, but enabling "USB CDC on Boot" frees them as plain GPIO.

Board data for all of the above lives in JSON, keyed by board id/FQBN, so more boards can be added without touching guardrail logic.

Configuration

Development

git clone https://github.com/hardware-mcp/arduino-mcp-servercd arduino-mcp-servernpm installnpm run typechecknpm testnpm run buildnpm run dev

Part of HardwareMCP

This server is part of the HardwareMCP ecosystem — a collection of MCP servers that give AI assistants real control over physical hardware.

License

MIT — see LICENSE.

Support

Open an issue