
PIO Agent
io.github.jl-codesPublished by GitHub account jl-codesv3.1.0Updated Oct 24, 2026
Build, inspect, flash, and monitor PlatformIO firmware projects with policy-controlled tools.
Overview
PIO Agent is a local MCP server and CLI that lets an assistant build, inspect, flash and monitor PlatformIO embedded firmware projects under policy controls.
- What you can do
- Discover boards and devices and initialize or inspect PlatformIO projects with exact project, environment and device bindings. Build firmware and get structured diagnostics for build, upload and serial failures. Flash firmware and monitor serial output with runtime assertions, bounded health checks and background task polling. Validate project readiness, audit GPIO pin safety and generate board intelligence reports. Inspect policy status, approval status and task history, and cancel tasks idempotently.
- When to use it
- Use it when an assistant should help with embedded firmware work on PlatformIO projects: setting up a board, building, diagnosing failures, or flashing and verifying a device. It suits developers who want agent-driven hardware workflows with approval gates rather than raw command execution.
- Requirements
- Runs as a local process over stdio, typically via npx with the platformio-mcp package. Needs Node.js 20 or newer and the PlatformIO Core CLI installed. A connected board and serial port are needed for flashing and monitoring. No authentication, environment variables or headers are declared.
Installation
In SourceWeft
- Open PIO Agent in the dashboard and add it to a workspace.
- Enable the server for the chats that should use its tools.
Desktop only via STDIO. STDIO servers start a local process, so they need the SourceWeft desktop host.
Other MCP clients
Follow the launch instructions in the repository.
README
PIO Agent
PIO Agent is the open-source, agent-first hardware execution layer for embedded development, built on the PlatformIO MCP runtime.
Release status
The canonical 3.1.0 runtime is published. The 3.2.0 candidate makes the
pio-agent CLI the primary adapter (nothing stays running unless asked), and
adds a native Codex panel and public plugin listing metadata. See the
changelog, compatibility guide,
and distribution readiness for implemented
behavior and the publication status of each package name.
Brand and Compatibility
PIO Agent is the product and Codex Plugin name. PlatformIO MCP is the underlying MCP runtime and the compatibility identity used by existing installations. The Codex plugin ID, marketplace ID, configuration keys, and skill namespace remain platformio-mcp. On npm, platformio-mcp is the canonical package while pio-mcp and pio-agent are thin compatibility packages that delegate to it. The canonical package also installs both platformio-mcp and pio-agent executable names. This lets existing consumers upgrade without migration while new users see PIO Agent throughout the interface.
It exposes PlatformIO workflows for board discovery, project setup, build, flash, monitor, diagnostics, and task orchestration through:
- an MCP server adapter
- a first-class CLI adapter (
platformio-mcp/pio-agent) - an optional local dashboard for visibility and control
MCP is one adapter. PlatformIO is the first backend.
Quick start (recommended)
No server, no client configuration, nothing left running between commands.
Using it with a coding agent
Install the skills and point your agent at the pio-agent binary. The
pio-manager skill documents every command.
MCP server (optional)
MCP remains fully supported for clients that prefer it:
Note that each session that connects this way runs its own server process. The CLI above avoids that. See Manual MCP Config below for other hosts.
Agent-First Capabilities
- Project readiness validation (
agent_validate_project) - Rich build diagnostics with structured error taxonomy (
agent_build_diagnose) - Board-aware GPIO safety audits (
agent_safe_pin_audit) - Flash + monitor + runtime assertions (
agent_flash_monitor_verify) - Persistent workflow artifacts in
.pio-mcp-workspace/(lastAgentReport.json,boardReport.json) - Board intelligence reports (
agent_generate_board_report) - Policy profile introspection (
get_policy_status) - Exact project/environment/device bindings (
agent_resolve_target) - Bounded, cursor-based serial health checks (
agent_monitor_health) - Idempotent task cancellation and compact history (
cancel_task,list_task_history) - Read-only approval status for agents; approval remains human-controlled
All risky operations still honor policy and approval rules.
Quick Start
1. Run the dashboard
2. Use the CLI
All three npm names are supported. platformio-mcp is canonical; pio-mcp and pio-agent install the same CLI through thin dependency-only aliases:
Use --json for machine-readable output:
3. Install into AI hosts
4. Install the full Codex Plugin
The PIO Agent Codex Plugin adds the bundled MCP runtime, focused embedded skills, secure in-app dashboard flow, and monitoring-automation guidance. Codex requires one stable plugin identifier, so install selectors and skill namespaces remain platformio-mcp; the installed product is shown as PIO Agent. From a clone:
From npm:
Start a new Codex task after installation. The legacy install --codex command remains available for MCP-only configuration. See the full Codex Plugin guide for update, uninstall, browser fallback, policy, automation, and rollback details.
The plugin release gates run on Windows, macOS, and Linux, exercise the authenticated dashboard in Chromium, validate the bundled runtime and public tool registry, and keep physical-board evidence in a separate manual workflow. That workflow uploads only bounded, sanitized evidence; raw hardware logs stay on the self-hosted runner. See the release and validation guide.
For headless verification and status inspection, the same CLI also provides plugin validate, target-resolve, monitor-status, monitor-health, task-history, approval-status, and pending-approvals. Run platformio-mcp --help for bounded options and JSON output support.
Manual MCP Config
On Windows, use npx.cmd if your host requires explicit shim resolution.
Core Capabilities
- Board and device discovery for PlatformIO-supported hardware
- Project initialization and config inspection
- Build, upload, monitor, and background task polling
- Structured diagnostics for build/upload/serial failures
- Safety and policy guardrails (approval gates, audit logs, redaction)
- Dashboard visibility for commands, logs, locks, and safety state
Safety Model
PIO Agent enforces policy decisions across CLI and MCP flows.
- Actions can be
allow,deny, orrequires_approval - Risky operations (for example firmware upload/reset paths) require explicit approval
- All actions can be audited
- Secrets are redacted in exposed log streams
Policy profiles can be selected per-project via .pio-mcp-policy.json:
Supported profiles:
read_onlybuild_onlymonitor_onlyflash_requires_approvallab_runner(explicit, expiring unattended-lab policy required)lab_admin
CLI approval workflows:
Codex Usage
Codex-facing docs and prompt cookbook:
Documentation
Getting started:
Guides and references:
- Agent Customization Guide
- MCP Server Command Reference
- Troubleshooting Guide
- Agent-First Embedded Workflow
- Competitive Positioning
- MCP-U Integration Template
- Agent Skills Directory
Specifications:
Development
Prerequisites:
- Node.js >= 20 (including the bundled direct-serial runtime)
- PlatformIO Core CLI (install guide)
Local setup:
CI/CD test tiers:
npm run test:ci:unitruns unit/component coverage used in cross-platform CI.npm run test:e2e:ciruns CI-safe end-to-end tests for agent workflows and CLI wiring..github/workflows/ci.ymlruns typecheck, tests, and package smoke checks on pull requests/pushes..github/workflows/hardware-e2e.ymlis a manual self-hosted-runner workflow for one explicitly confirmed physical-board write, bundled-plugin protocol checks, post-flash identity/serial assertions, cleanup proof, and sanitized evidence.
Contributing
Contributions are welcome.
- Open an issue for bugs or feature requests
- Submit a pull request with tests when applicable
License
MIT. See LICENSE.
Firmware crash and size analysis
The MCP tools decode_backtrace and size_report analyze an explicitly selected project/environment using its registered GNU toolchain. Metadata and memory checks require build permission because they can execute project scripts. Reports identify the exact ELF, retain unresolved crash addresses, and distinguish PlatformIO memory usage from GNU estimates. They do not prove which firmware is on a device. See firmware analysis for inputs, approval behavior, evidence and current limits.
Source: README.md at commit f3928e8
Tools
0Version history
1- v3.1.0LatestSep 26, 2026
Score
50% of the applicable checks met
How complete this listing is, computed from the registry entry, the endpoint and public sources. Not a rating of the server and not a statement that it is safe or working today: reachability is a dated check, and no installs or reviews go into the score.
- Reached in the last 30 days25 pts
Keep the endpoint answering the MCP handshake; SourceWeft probes it every 30 days.
- Auth declared10 pts
Declare the credential headers in the registry entry, or keep the endpoint answering the probe so its auth can be classified.
- Tools listed15 pts
Answer tools/list without a credential, or ship a package that starts in a sandbox without one.
- DescriptionRequired15 pts
- Logo10 pts
- Documentation15 pts
- License10 pts