Skip to main content
Glama
niradler

Arduino MCP Server

by niradler
OverviewSchemaSourceRelated ServersScoreDiscussionsAdmin
Python
Local

Arduino MCP Server

A comprehensive Model Context Protocol (MCP) server for Arduino CLI interactions, built with FastMCP. This server enables AI agents to seamlessly interact with Arduino CLI for development, debugging, code verification, and more.

Features

🛠️ Tools (All 3 MCP Pillars)

  • CLI Management: Check installation, get help for commands

  • Board Detection: List connected boards, find Arduino ports, auto-detect best port

  • Core Management: Search, install, and list Arduino cores

  • Library Management: Search, install, and list Arduino libraries

  • Sketch Operations: Create, compile, and upload sketches

  • Enhanced Serial Monitor: Bidirectional communication, buffering, file export

  • Image Conversion: Convert images to C arrays for display applications (requires ImageMagick)

  • Configuration: Initialize config, clean cache

📚 Resources

  • sketch://{path} - Read Arduino sketch files (.ino, .cpp, .h)

  • arduino-config://main - Access Arduino CLI configuration

  • board-info://{fqbn} - Get detailed board information

💡 Prompts

  • Blink LED Example: Basic LED blinking sketch template

  • Sensor Reading Example: Analog sensor reading template

  • Sketch Project Workflow: IDE-like experience with board attach

  • Full Development Workflow: Complete Arduino development guide

  • Troubleshooting Guide: Common issues and solutions

🚀 Advanced Features

  • Logging: Comprehensive logging with info, warning, error levels (source)

  • Progress Reporting: Real-time progress updates for long operations (source)

  • Context Integration: Full MCP context support for enhanced interactions (source)

  • Annotations: Proper tool annotations for better UX (readOnly, destructive, openWorld hints)

Related MCP server: FastMCP Server

Prerequisites

Environment Variables

Customize the server behavior with these optional environment variables:

Variable

Default

Description

ARDUINO_CLI_PATH

arduino-cli

Path to Arduino CLI executable

MCP_SKETCH_DIR

OS-specific*

Override default sketch directory

ARDUINO_SERIAL_BUFFER_SIZE

10

Serial buffer size in MB

ARDUINO_CONFIG_FILE

Auto-detected

Custom Arduino CLI config file path

*Default sketch directories:

  • Windows: %DOCUMENTS%\Arduino

  • macOS: ~/Documents/Arduino

  • Linux: ~/Arduino

Installation

  1. Clone this repository:

git clone <your-repo-url>
cd arduino-mcp

  1. Install dependencies with uv:

uv sync

  1. Install Arduino CLI:

# Windows (using winget)
winget install ArduinoSA.CLI

# macOS
brew install arduino-cli

# Linux
curl -fsSL https://raw.githubusercontent.com/arduino/arduino-cli/master/install.sh | sh

Usage

Running the Server

Using uv:

uv run python -m arduino_mcp.server

Using FastMCP CLI:

uv run fastmcp run arduino_mcp/server.py:mcp

For HTTP transport:

uv run fastmcp run arduino_mcp/server.py:mcp --transport http --port 8000

Configuration for MCP Clients

For Cursor IDE

The project includes .cursor/mcp.json configuration. Cursor will automatically detect it when you open the project.

Alternatively, add to your global Cursor settings:

{
  "mcpServers": {
    "arduino": {
      "command": "uvx",
      "args": ["arduino-mcp"]
    }
  }
}

For Claude Desktop

Add to your MCP configuration file:

Windows: %APPDATA%\Claude\claude_desktop_config.json
macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Linux: ~/.config/Claude/claude_desktop_config.json

{
  "mcpServers": {
    "arduino": {
      "command": "uvx",
      "args": ["arduino-mcp"]
    }
  }
}

Testing

To verify the Arduino MCP server is working:

# Test import
uv run python -c "from arduino_mcp import mcp; print('Server imports successfully')"

# Start the server
uv run fastmcp run arduino_mcp/server.py:mcp

Once running in Cursor IDE, you can test the tools directly in the chat interface.

Example Workflows

1. Project-Based Workflow with Board Attach (Recommended)

# Find your connected board
list_connected_boards()

# Create a new sketch
create_new_sketch("MyProject")

# Attach board settings to sketch (IDE-like experience!)
arduino_cli_command("board attach -p COM3 -b arduino:avr:uno MyProject")

# This creates sketch.yaml with your board settings

# Now compile and upload without repeating FQBN/port
compile_sketch("MyProject", "")  # Reads from sketch.yaml
upload_sketch("MyProject", "", "")  # Reads from sketch.yaml

# Monitor serial output with bidirectional communication
serial_monitor(
    port="COM3",
    baudrate=115200,
    duration=30,
    send_commands="LED ON\nLED OFF",  # Send commands to device
    save_to_file="output.log"  # Save buffer to file
)

Why use board attach?

  • Settings persist per-sketch (not globally)

  • No need to repeat FQBN and port every time

  • Team-friendly (sketch.yaml can be version controlled)

  • Works exactly like Arduino IDE 2.x

2. Basic Setup and Blink LED

# Check if Arduino CLI is installed
check_arduino_cli_installed()

# Find connected Arduino boards
list_connected_boards()
find_arduino_ports()
get_best_port()

# Create a new sketch
create_new_sketch("BlinkLED", "./sketches")

# Use the blink_led_example prompt for code template

# Compile the sketch
compile_sketch("./sketches/BlinkLED", "arduino:avr:uno")

# Upload to board
upload_sketch("./sketches/BlinkLED", "arduino:avr:uno", "COM3")

2. Basic Setup and Blink LED

# Check if Arduino CLI is installed
arduino_cli_command("version")

# Find connected Arduino boards
list_connected_boards()
list_ports(arduino_only=True)

# Create a new sketch
create_new_sketch("BlinkLED", "./sketches")

# Use the blink_led_example prompt for code template

# Compile the sketch
compile_sketch("./sketches/BlinkLED", "arduino:avr:uno")

# Upload to board
upload_sketch("./sketches/BlinkLED", "arduino:avr:uno", "COM3")

# Monitor output
serial_monitor("COM3", baudrate=115200, duration=20)

3. Library Installation and Usage

# Search for a library
search_libraries("Adafruit SSD1306")

# Install the library
install_library("Adafruit SSD1306")

# List installed libraries
list_installed_libraries()

4. Enhanced Serial Monitor Features

# Basic monitoring (115200 is now the default)
serial_monitor("COM3", duration=30)

# Send commands while monitoring (bidirectional)
serial_monitor(
    port="COM3",
    baudrate=115200,
    duration=30,
    send_commands="GET_STATUS\nSET_LED 1"
)

# Save buffer to file for analysis
serial_monitor(
    port="COM3",
    baudrate=115200,
    duration=60,
    save_to_file="sensor_data.log"
)

# Combined: send commands and save output
serial_monitor(
    port="COM3",
    baudrate=115200,
    duration=45,
    send_commands="START_LOGGING",
    save_to_file="experiment_results.txt"
)

Buffer Features:

  • Circular buffer (10MB default, configurable via env var)

  • Memory-safe (won't crash on long-running captures)

  • Thread-safe operation

  • Automatic statistics (lines captured, buffer usage)

5. Image to C Array Conversion

# Check ImageMagick installation
check_imagemagick_installed()

# Convert image to C array for Arduino displays
convert_image_to_c_array(
    "logo.png",
    width=128,
    height=64,
    var_name="logo_bitmap",
    output_file="logo.h"
)

6. Resource Access

# Read a sketch file
read_resource("sketch://./BlinkLED/BlinkLED.ino")

# Get Arduino configuration
read_resource("arduino-config://main")

# Get board details
read_resource("board-info://arduino:avr:uno")

Tools Reference

Board & Port Detection

  • check_arduino_cli_installed() - Verify Arduino CLI installation

  • list_connected_boards() - List all connected Arduino boards

  • list_serial_ports() - List all serial ports

  • find_arduino_ports() - Find Arduino-specific ports

  • get_best_port() - Auto-detect best port candidate

  • verify_port(port) - Verify if a port is accessible

Core Management

  • list_installed_cores() - List installed Arduino cores

  • search_cores(query) - Search for Arduino cores

  • install_core(core) - Install an Arduino core

Library Management

  • search_libraries(query) - Search for Arduino libraries

  • install_library(library) - Install an Arduino library

  • list_installed_libraries() - List installed libraries

Sketch Operations

  • create_new_sketch(name, path) - Create a new Arduino sketch

  • compile_sketch(path, fqbn) - Compile an Arduino sketch

  • upload_sketch(path, fqbn, port) - Upload sketch to board

Utilities

  • get_arduino_help(command) - Get help for Arduino CLI commands

  • initialize_config() - Initialize Arduino CLI configuration

  • clean_cache() - Clean Arduino CLI cache

  • check_imagemagick_installed() - Check ImageMagick installation

  • convert_image_to_c_array(...) - Convert images to C arrays

Common FQBNs

  • Arduino Uno: arduino:avr:uno

  • Arduino Mega 2560: arduino:avr:mega

  • Arduino Nano: arduino:avr:nano

  • Arduino Leonardo: arduino:avr:leonardo

  • ESP32: esp32:esp32:esp32

  • ESP8266: esp8266:esp8266:generic

Architecture

arduino-mcp/
├── arduino_mcp/
│   ├── __init__.py          # Package initialization
│   ├── server.py            # Main MCP server with tools, resources, prompts
│   ├── cli_wrapper.py       # Arduino CLI wrapper
│   ├── port_detector.py     # Serial port detection utilities
│   ├── image_converter.py   # ImageMagick image conversion
│   └── platform_utils.py    # Cross-platform OS detection & handling
├── pyproject.toml           # Project configuration
└── README.md               # This file

Cross-Platform Design

  • platform_utils.py: Centralized OS detection and platform-specific behavior

  • Automatic detection: Windows (COM*), macOS (/dev/tty.), Linux (/dev/ttyUSB, /dev/ttyACM*)

  • Serial keywords: Platform-specific Arduino device identification

  • Error handling: PermissionError for Linux, graceful fallbacks

  • Path handling: OS-appropriate path separators and formats

Contributing

Contributions are welcome! Please feel free to submit issues or pull requests.

References

License

MIT License

Available Tools

16 tools
arduino_cli_commandExecute Raw Arduino CLI CommandD
ParametersJSON Schema
NameRequiredDescriptionDefault
commandYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

D1/5.0
Behavior1/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Tool has no description.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Tool has no description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines1/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Tool has no description.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

clean_cacheD
ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

D1/5.0
Behavior1/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Tool has no description.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Tool has no description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines1/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Tool has no description.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

compile_sketchCompile Arduino SketchA

Compile an Arduino sketch.

TIP: If you used arduino-cli board attach on this sketch, FQBN is optional! The board settings will be read from sketch.yaml automatically.

For project-based workflows, use board attach first: arduino_cli_command("board attach -p COM3 -b arduino:avr:uno MySketch")

Then compile without specifying FQBN each time. See the sketch_project_workflow prompt for details.

ParametersJSON Schema
NameRequiredDescriptionDefault
sketch_pathYes
fqbnYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A3.7/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations indicate readOnlyHint=false, suggesting modification. Description adds detail about FQBN optionality but lacks disclosure on output, side effects, or error conditions beyond annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Concise with clear TIP section. Every sentence adds value, but slightly verbose with the board attach example.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Lacks explanation of return values or typical output despite having an output schema. Missing details on parameter formats. Adequate but could be more complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0% and description only mentions FQBN optionality, not defining either parameter's format or meaning. Fails to compensate for low schema coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Clearly states 'Compile an Arduino sketch' using a specific verb and resource. Differentiates from sibling tools like upload_sketch or serial_monitor.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides TIP about FQBN optionality and alternative workflow using board attach, giving clear context for when to use the tool. Does not explicitly list alternatives but sibling tools are provided separately.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

convert_image_to_c_arrayConvert Image to C Array for Hardware DisplaysA

Convert images to C arrays for hardware displays (OLED, E-Paper, TFT, LEDs)

Supports: monochrome (1-bit), grayscale_2bit (4-level), grayscale_4bit (16-level), grayscale (8-bit), rgb565 (16-bit color), rgb888 (24-bit color)

Parameters:

  • rotation: 0, 90, 180, or 270 degrees (test all to find correct orientation)

  • threshold: Black/white cutoff for monochrome (e.g., "50%", "60%", "70%")

  • keep_aspect: True to maintain proportions, False to force exact size

ParametersJSON Schema
NameRequiredDescriptionDefault
image_pathYes
widthYes
heightYes
var_nameYes
format_typeNomonochrome
output_fileNo
invertNo
rotationNo
thresholdNo
keep_aspectNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A3.6/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations indicate readOnlyHint=false and openWorldHint=true. The description reveals behavioral details like rotation options and threshold for monochrome, but does not disclose potential side effects (e.g., writing output files, required permissions) or error conditions. Some value beyond annotations is added, but gaps remain.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is relatively concise, using a bullet-like list for format types and parameter notes. It avoids unnecessary detail but could be streamlined further. The format is scannable, though the parameter list duplicates some info from the schema.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With an output schema present, return values need not be explained, but the description still must cover all parameters and operational context. With 10 parameters, only 3 are partially described, leaving significant gaps. The tool's behavior for required fields like image_path and var_name is not addressed, making the description incomplete for effective use.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 0% description coverage, placing full burden on the description. However, the description only explains 3 of 10 parameters (rotation, threshold, keep_aspect) with brief notes. Key parameters like image_path, width, height, var_name, and format_type remain unexplained, providing insufficient semantic context.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The title and description clearly state the tool converts images to C arrays for hardware displays, listing supported color formats. It distinctly differs from sibling tools which are Arduino CLI commands and development utilities, leaving no ambiguity about its purpose.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description specifies the tool is for hardware displays (OLED, E-Paper, TFT, LEDs), providing clear context. While it does not explicitly mention when not to use it or name alternatives, the sibling set contains no other image conversion tools, making the usage scope unambiguous.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

create_new_sketchD
ParametersJSON Schema
NameRequiredDescriptionDefault
sketch_nameYes
pathNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

D1/5.0
Behavior1/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Tool has no description.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Tool has no description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines1/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Tool has no description.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

install_coreInstall Arduino CoreD
ParametersJSON Schema
NameRequiredDescriptionDefault
coreYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

D1/5.0
Behavior1/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Tool has no description.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Tool has no description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines1/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Tool has no description.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

install_libraryInstall Arduino LibraryD
ParametersJSON Schema
NameRequiredDescriptionDefault
libraryYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

D1/5.0
Behavior1/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Tool has no description.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Tool has no description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines1/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Tool has no description.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

lint_arduino_projectLint Arduino ProjectB
Read-only

Lint Arduino project for compliance and best practices.

ParametersJSON Schema
NameRequiredDescriptionDefault
project_pathYesPath to sketch, library, or platform
complianceNo"permissive", "specification", or "strict"specification
library_managerNoNone, "submit", or "update" for Library Manager checks

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

B3.1/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already indicate readOnlyHint=true and openWorldHint=true, so the safety profile is clear. The description adds 'lint' as a behavioral trait but no further details on what checks are performed or side effects.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single concise sentence with no wasted words. It is front-loaded, though it could benefit from slight expansion.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Despite having an output schema, the description fails to mention what the tool returns, leaving the agent uninformed about the result format or content.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with all parameters documented. The description does not add extra meaning beyond what is in the schema, achieving the baseline.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool lints Arduino projects for compliance and best practices, which is specific. However, it does not differentiate from sibling tools, but none are similar, so it remains effective.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool versus alternatives. The description lacks context about prerequisites or scenarios, leaving the agent to infer usage.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

list_connected_boardsD
Read-only
ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

D1/5.0
Behavior1/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Tool has no description.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Tool has no description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines1/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Tool has no description.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

list_installed_coresD
Read-only
ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

D1/5.0
Behavior1/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Tool has no description.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Tool has no description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines1/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Tool has no description.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

list_installed_librariesD
Read-only
ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

D1/5.0
Behavior1/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Tool has no description.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Tool has no description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines1/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Tool has no description.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

list_portsList Serial PortsD
Read-only
ParametersJSON Schema
NameRequiredDescriptionDefault
arduino_onlyNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

D1/5.0
Behavior1/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Tool has no description.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Tool has no description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines1/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Tool has no description.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

serial_monitorEnhanced Serial Monitor with Bidirectional CommunicationD
ParametersJSON Schema
NameRequiredDescriptionDefault
portYes
durationNo
baudrateNo
send_commandsNo
save_to_fileNo
reset_boardNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

D1/5.0
Behavior1/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Tool has no description.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Tool has no description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines1/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Tool has no description.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

upload_sketchUpload Sketch to BoardA
Destructive

Upload a compiled sketch to an Arduino board.

TIP: If you used arduino-cli board attach on this sketch, FQBN and port are optional! The settings will be read from sketch.yaml automatically.

For project-based workflows, use board attach first: arduino_cli_command("board attach -p COM3 -b arduino:avr:uno MySketch")

Then upload without specifying FQBN/port each time. See the sketch_project_workflow prompt for details.

ParametersJSON Schema
NameRequiredDescriptionDefault
sketch_pathYes
fqbnYes
portYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.3/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already indicate destructiveHint=true, but description adds context: uploading modifies board state, optional parameters if board attached, and links to board attach workflow. No contradiction with annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

First sentence states purpose directly. TIP and example are front-loaded but the description is somewhat lengthy. Could be more concise while retaining essential guidance.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With 3 parameters, annotations, and output schema present, the description covers optional parameters and workflow adequately. Lacks explicit return value explanation but schema handles it.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so description must carry burden. It implicitly explains fqbn and port as optional via board attach and mentions sketch_path in example, but does not explicitly define each parameter's meaning or format.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

First sentence clearly states 'Upload a compiled sketch to an Arduino board.' Verb 'upload' and resource 'sketch to Arduino board' are specific. Distinguishes from siblings like compile_sketch and list_connected_boards.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides TIP about optional parameters when board attach is used, references sketch_project_workflow prompt, and gives example of using board attach first. Explicitly tells when to omit FQBN/port.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

verify_portD
Read-only
ParametersJSON Schema
NameRequiredDescriptionDefault
portYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

D1/5.0
Behavior1/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Tool has no description.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Tool has no description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines1/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Tool has no description.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. 16 tool updatesv0.1.3
    • First observedarduino_cli_command
    • First observedclean_cache
    • First observedcompile_sketch
    • First observedconvert_image_to_c_array
    • First observedcreate_new_sketch
    • First observedinstall_core
    • First observedinstall_library
    • First observedlint_arduino_project
    • First observedlist_connected_boards
    • First observedlist_installed_cores
    • First observedlist_installed_libraries
    • First observedlist_ports
    • First observedsearch
    • First observedserial_monitor
    • First observedupload_sketch
    • First observedverify_port
Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

C2.2/5.0

Scored across 16 tools

Disambiguation2/5

Many tools lack descriptions, and 'arduino_cli_command' is overly generic, potentially overlapping with other tools. Several tools like 'clean_cache' are ambiguous, making it hard for agents to distinguish purposes.

Naming Consistency4/5

Most tools follow a verb_noun pattern with snake_case, but 'arduino_cli_command' is noun_noun and 'search' is just a verb, causing minor inconsistency.

Tool Count5/5

16 tools cover a wide range of Arduino operations without being overwhelming. Each tool serves a distinct aspect of the development workflow.

Completeness4/5

Core CRUD and lifecycle operations for sketches, libraries, cores, boards, and serial monitoring are present. Missing explicit delete or update tools, but the generic 'arduino_cli_command' can cover gaps.

Maintenance

ActivityInactive
ResponsivenessNo issues

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Related MCP Servers

  • arduino-claude-mcp

    eoinjordan
    A
    license
    Not graded
    quality
    D
    maintenance
    MCP server for Arduino IDE 2.0 sketches. It exposes a small REST API plus an MCP stdio bridge so agents can read and write the main .ino file, list sources, and optionally compile with arduino-cli.
    18
    MIT

  • FastMCP Server

    jamesbspencer
    A
    license
    Not graded
    quality
    B
    maintenance
    A high-performance personal Model Context Protocol (MCP) server built with the FastMCP Python framework.
    MIT

  • Mixly Local MCP

    ovoVHV
    F
    license
    Not graded
    quality
    A
    maintenance
    A fully local MCP server for Mixly that lets AI clients discover boards, scan blocks, build/validate/open projects, generate code, and compile via Arduino CLI—all without uploading source or relying on a remote server.
    2
    -

  • arduino-mcp

    JShort-bufr
    F
    license
    A
    quality
    C
    maintenance
    A local stdio MCP server wrapping arduino-cli to let agents detect boards, manage cores/libraries, compile and upload sketches, and communicate over serial, enabling hardware control without shell gymnastics.
    17
    -

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/niradler/arduino-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server