MCP

Simulator86 runs an MCP server, so a coding agent — Claude Code, Cursor, Codex, and others — can build a board, flash firmware, start a simulation, and read back what happened, without you leaving the conversation.

Connect

One command. It checks the selected client, opens a browser, and asks you to approve the connection while signed in. It then configures that client directly. No key to copy and no JSON or TOML to paste.

# macOS / Linux
curl -fsSL https://mcp.sim86.com | sh

# Windows
irm "https://mcp.sim86.com?tool=claude" | iex

Pass your agent as the argument if it isn’t Claude Code — sh -s -- cursor, codex, vscode, opencode. On Windows, change the query to ?tool=cursor, ?tool=codex, ?tool=vscode, or ?tool=opencode. Prefer to wire it yourself? The endpoint is https://mcp.sim86.com/mcp (streamable HTTP); send Authorization: Bearer sim86_live_… from Cloud → API keys and skip the browser step.

The installer writes only the sim86 entry in the selected client’s user configuration. Re-run it to rotate the credential, then restart the client or open a fresh agent session so it loads the new MCP server.

What the agent can do

• get_components — placeable parts with pin and RF-capability metadata
• create_project / list_projects — a workspace to build in
• upload_file — put a file from your machine in the project workspace
• start_simulation — flash firmware and run the graph
• run_status / list_runs — read results and history
• sample_stream / get_logs — inspect live component state and firmware UART/RTT output
• wifi_fetch — request a page hosted by firmware through the simulated Wi-Fi/RF path
• open_wifi_browser — give you a short-lived, one-use URL for the same device page in a real browser tab

RF is not a pin or wire. For Wi-Fi simulations, the agent gets the exact catalog types from get_components, places an RF Environment and a Wi-Fi Network, and adds both radio devices’ IDs to the environment’s config.members. The Wi-Fi Network supplies infrastructure service and the browser-client point of view. The first release supports open networks and plain http://.

Firmware artifacts are board-specific. Most MCU components take the ELF your linker produced; the XIAO ESP32-C3 takes a merged flash .bin. If a run fails, the agent gets a plain reason back.

Firmware does not travel through the agent’s context. upload_file hands back a curl that posts the file straight from your machine into the project’s workspace; the agent then starts the run with that path. A 4MB ESP32 flash image would be ~5.6MB of base64 as a tool argument — this is what makes those boards launchable at all. It is not firmware-specific: anything the firmware needs to read can go the same way.

Uploads land in the project’s file tree, where you can see them in the editor, and re-uploading a path replaces it. Nothing to configure: the command carries a signed, ten-minute upload ticket scoped to that one project and path, so the agent never needs — and never sees — your API key.

Which components exist

The full parts list — MCUs, sensors, displays, peripherals — is in the Components overview. Ask your agent “what can you simulate?” and it reads the same list live.

---

Connected in one line, your agent can reproduce a firmware bug or check a change against real peripheral behavior while it writes the code. Point it at a project and ask it to run something.