Loading ToolBench
MCP Server for Arduino CLI providing sketch, board, library, and file management tools.
This Arduino MCP server has 22 tools with consistent naming following verb-noun patterns (create_, list_, read_, write_, verify_, upload_, search_, generate_, serial_). However, definition quality is severely hampered by several critical issues: (1) descriptions lack LLM-optimization depth, most are 80-150 chars, stating WHAT the tool does but rarely WHEN to use it or prerequisites; (2) parameter descriptions are present but often minimal (e.g., 'Serial port (e.g., /dev/ttyUSB0, COM3)', no explanation of why this is needed or how to find it); (3) output schemas are completely undocumented, no tool specifies what fields are returned, making it impossible for LLMs to chain calls or extract data; (4) error handling is absent from descriptions, no guidance on retryability, failure modes, or recovery paths; (5) security-critical tools like set_openai_api_key() expose credentials as parameters, violating pattern:secret-injection. Naming is strong (verb-first, clear intent), but the lack of output documentation and minimal parameter depth significantly limit usability. The server reads well as code documentation, but fails as an agent-facing interface.
Create a new Arduino sketch (.ino file) with an optional header comment and automatically open it in the default editor.
Generate a circuit diagram from WireViz YAML configuration and automatically open the resulting PNG image in the default viewer.
Provide basic usage instructions for WireViz including YAML syntax examples and common use cases.
Install a library by its exact name from the online index.
List all available examples from installed Arduino libraries.
Search the online Arduino library index using fuzzy search for advanced matching.
List all connected Arduino boards with their ports and FQBNs.
Output schemas completely undocumented across all 22 tools. No tool specifies return type, fields, or structure. This prevents agents from chaining calls, extracting data, or validating responses.
Credentials exposed as tool parameter (set_openai_api_key). API keys must never be parameters, they enter logs, traces, and prompt history. Should use environment variable or vault injection.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 64 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 0 | - | v1 |
List all sketches in the configured sketches base directory.
Read and return the contents of a sketch file.
Remove (delete) a file within allowed directories. This operation is destructive and cannot be undone.
Rename a file within allowed directories (user home or Arduino-related directories). Security-restricted to prevent access outside allowed paths.
Search the online Arduino board index for boards matching a query.
Clear the output buffer for an active serial connection.
Connect to a serial port and start monitoring output.
Disconnect from a serial port and stop monitoring.
List all active (connected) serial connections and their status.
Read buffered output from an active serial connection.
Write data to an active serial connection.
Set the OpenAI API key for GPT-4 API calls.
Compile and upload a sketch to a connected board. Requires an FQBN and optionally a port.
Compile (verify) a sketch without uploading. Requires an FQBN (Fully Qualified Board Name) to specify the target board.
Write or overwrite a file within the allowed directories. If writing to a .ino file within the sketch directory, automatically triggers compilation verification using the specified FQBN (or default).
Error handling absent from all tool descriptions. No guidance on retryability, failure modes (timeout, permission denied, not found), or recovery paths. Agents cannot distinguish between transient vs fatal errors.
Destructive operations (write_file, remove_file) lack confirmation or dry-run support. Agents may accidentally overwrite or delete without warning. No undo/recovery guidance.
Tool descriptions lack LLM optimization depth. Most are 50-100 characters stating only WHAT, not WHEN to use or prerequisites. Baseline A+ tools average 194 chars with complete context. E.g., 'List all sketches in the configured sketches base directory.' doesn't explain why an agent would call this (discovery before read/edit?) or what the output structure is.
Parameter descriptions sometimes lack actionable detail. E.g., 'Optional FQBN for auto-compile when writing .ino files. Defaults to arduino:avr:uno.' lacks format constraint or how to discover valid FQBNs. 'Serial port (e.g., /dev/ttyUSB0, COM3)' example values may be reused literally by LLMs instead of adapted to actual context.
No pagination support documented for list tools (list_sketches, list_boards, lib_list_examples, serial_list_active). If result counts are large, context window exhaustion is likely. Should include limit/offset params and total count in responses.
Tool chaining dependencies not documented. E.g., search_boards returns board matches, but it's unclear what field (FQBN? name?) flows into upload_sketch. Same for lib_search → lib_install. Missing field names force LLMs to guess or call discovery tools unnecessarily.
Generic tool names reduce clarity. 'write_file' and 'rename_file' apply to any file system path, not just Arduino sketches. Consider Arduino-scoped names like 'write_sketch', 'rename_sketch' for clarity, or at minimum document allowed directories in descriptions.