arduino-mcp-server
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."
| Tool | What it does |
|---|
arduino_cli_doctor | Check Arduino CLI installation and version |
install_arduino_cli | Guide through arduino-cli installation |
detect_hardware | Detect connected boards and infer FQBNs |
list_connected_boards | List all connected Arduino boards |
list_serial_ports | List available serial ports |
ensure_core_installed | Check/install board cores |
compile_sketch | Compile a sketch for a target board |
upload_sketch | Upload compiled sketch to a board |
upload_and_wait_ready | Upload and wait for device ready signal |
serial_open_session | Open a stateful serial session |
serial_read | Read buffered serial data |
serial_expect | Wait for a pattern in serial output |
serial_write | Send data over serial |
serial_close_session | Close a serial session |
serial_list_sessions | List active serial sessions |
read_serial_snapshot | Quick one-shot serial read |
safety_preflight | Electrical safety check before hardware ops |
get_board_details | Get pin/capability details for a board |
list_supported_boards | List all boards arduino-cli supports |
list_board_reference | Browse board pin reference |
search_board_reference | Search board reference by keyword |
Resources:
arduino://boards/reference — structured board pin/capability reference
Prompts:
arduino-cli-bootstrap-policy — policy for arduino-cli setup behaviorarduino-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 1CBATTERY_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
| Variable | Default | Description |
|---|
ARDUINO_CLI_PATH | arduino-cli | Path to arduino-cli binary |
ARDUINO_SKETCH_ROOT | (none) | Restrict sketch paths to this directory |
Development
git clone https://github.com/hardware-mcp/arduino-mcp-server
cd arduino-mcp-server
npm install
npm run typecheck
npm test
npm run build
npm 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