Wokwi

Wokwi works inside its own simulator and does not reach into other software on an agent's behalf. Its MCP tools start and stop simulations, talk to the serial monitor, read pins, set part controls and capture screenshots, all within the running project.

A simulated ESP32 can join the Wokwi-GUEST WiFi network and send MQTT, HTTP, HTTPS or WebSocket traffic out to the internet. Paying users can route that traffic through a Private IoT Gateway on their own computer, which also lets the firmware reach services on the local network and accept incoming connections. That traffic comes from the firmware under test. Wokwi offers no connectors for an agent to act in outside services.

Sourcedocs.wokwi.com/wokwi-ci/mcp-supportread 2026-10-08

Each Wokwi run is one simulation that the caller starts, stops, resumes or restarts. Automation scenarios lay out a fixed sequence for a single board: set a control, wait, check serial output, compare a screenshot. Teams with long suites split them into several CI runs.

Wokwi does not coordinate several agents or chain work from one run into the next. That sequencing stays with the calling agent or the CI pipeline.

Sourcedocs.wokwi.com/wokwi-ci/automation-scenariosread 2026-10-08

Wokwi stores projects, wiring diagrams and parts. Its MCP server hands an agent the project's wokwi.toml and diagram.json files as readable resources, so the agent can see which firmware is loaded and how the board is wired, and a simulation start returns any diagram lint warnings.

Those files describe the board under simulation. Wokwi keeps no knowledge base over a customer's documents and has no assistant that answers questions from one.

Sourcedocs.wokwi.comread 2026-10-08

Agents call the MCP tools directly, and each call takes effect straight away, whether it starts a simulation, changes a sensor value or writes to the serial port. Wokwi has no step where a person reviews or approves what an agent is about to do. The MCP server itself is still labeled experimental in the docs and in the CLI's README.

Sourcedocs.wokwi.com/wokwi-ci/mcp-supportread 2026-10-08

Access rests on Wokwi accounts and API tokens. A CI token is created in the Wokwi CI Dashboard, starts with wok_, runs to 44 characters and is passed to the CLI, the GitHub Action or the MCP server as an environment variable or repository secret. The VS Code extension is licensed by signing in to a Wokwi account from the editor.

Wokwi Pro adds per seat billing, team invoices and unlisted projects. Wokwi does not offer single sign on, user roles or team permission settings, and it publishes no security page, trust center or certification.

Sourcedocs.wokwi.com/wokwi-ci/cli-usageread 2026-10-08

Each run leaves evidence about the firmware: the serial log, which the CLI can save to a file, logic analyzer captures exported as VCD files, and screenshots of display parts taken at a set point in simulated time. CI time is metered against an allowance measured over a rolling 30 days, with a wall clock limit on each session.

Wokwi keeps no audit trail of which user, token or agent started a run or what it changed.

Sourcedocs.wokwi.com/wokwi-ci/getting-startedread 2026-10-08

Within one MCP session, stopping a simulation pauses it, and the resume tool picks it up where it left off; restart begins again from scratch. Serial output builds up in a buffer the agent can read with or without clearing it.

A simulated microSD card can be preloaded from a folder or an image and written back when the run stops or restarts, so the next run starts with the files the firmware left behind. All of that is the board's own state. Wokwi keeps no record of an agent's earlier sessions for it to draw on.

Sourcegithub.com/wokwi/wokwi-cliread 2026-10-08

Simulations run on Wokwi's cloud by default. Wokwi CI uses a stateless server that runs simulations in parallel and deletes the firmware after each one, and on premises deployment is available by contacting Wokwi.

On the Pro plan, the VS Code extension can also run offline from a simulator engine stored on the developer's machine, refreshing it whenever it next goes online. For machines with no internet access at all, Wokwi prepares a custom offline installation package on quote. The cloud service offers no choice of hosting region.

Sourcedocs.wokwi.com/vscode/offline-moderead 2026-10-08

A lot comes ready to run. The simulator supports about 17 microcontroller types: AVR boards such as the Arduino Uno, Mega and Nano plus the ATtiny85, ten ESP32 chips across Xtensa and RISC-V, three STM32 parts and the Raspberry Pi Pico. Around 66 documented parts sit alongside them, from sensors, displays and motors to a logic analyzer and a microSD card.

Wokwi also publishes starting projects, such as an ESP-IDF hello world repository, example custom chips (an EEPROM, OLED and LCD drivers, a logic analyzer with protocol decoding) and community projects on wokwi.com. These are boards and projects to build from; Wokwi offers no prebuilt agents.

Sourcedocs.wokwi.com/getting-started/supported-hardwareread 2026-10-08

A simulation starts when someone opens a project in the browser or in VS Code, when the CLI runs, or when an agent calls the MCP server. In CI, the wokwi-ci-action step runs after the firmware build inside the customer's own GitHub workflow, on whatever events that workflow already listens to.

Wokwi itself has no scheduler, webhook or event listener that starts a simulation on its own.

Sourcedocs.wokwi.com/wokwi-ci/getting-startedread 2026-10-08

No AI model runs inside Wokwi. The coding agent that connects to the MCP server brings its own model, and the docs name Copilot, Claude Code, Cursor, Gemini and ChatGPT as clients. Wokwi has no setting for choosing a model.

Sourcedocs.wokwi.com/wokwi-ci/mcp-supportread 2026-10-08

A command line tool and an SDK open the simulator to code. With a CI token, the Wokwi CLI runs projects described in wokwi.toml and diagram.json, lints diagrams for unknown parts and bad pin connections, exports logic analyzer traces, preloads SD cards and starts a GDB server.

Running wokwi-cli mcp starts the MCP server over stdio. The open source CLI defines its eleven tools for starting, stopping, resuming and restarting a simulation, checking status, reading and writing serial data, reading pins, setting part controls, taking screenshots and exporting VCD files, plus the project's two config files as resources.

The Chips API, in beta, is an SDK for writing custom parts in C or another language that compiles to WebAssembly, with calls for GPIO, analog, timers, UART, I2C, SPI, attributes and framebuffers, and experimental Verilog support.

Sourcedocs.wokwi.com/chips-api/getting-startedread 2026-10-08

A firmware build becomes a pass or fail check. The CLI fails a run when expected serial text never appears or when forbidden text does, and exits with a set code, 42 by default, when the simulation times out. YAML automation scenarios press buttons, change sensor values, check pin levels, wait for serial output and compare a display with a saved screenshot, though Wokwi still labels scenarios alpha.

The wokwi-ci-action runs these checks in GitHub Actions after each build. On ESP32 boards, an instruction coverage file records which addresses ran and how often each branch was taken, and a GDB server lets a developer step through the simulated firmware from VS Code or the command line.

Sourcedocs.wokwi.com/wokwi-ci/cli-usageread 2026-10-08

Agents reach Wokwi through MCP tool calls and the CLI rather than through a screen. The browser simulator and the VS Code extension are built for people, and the screenshot tool captures a simulated display part such as an OLED, not a desktop. No browser or desktop session is operated by the agent.

Sourcedocs.wokwi.com/wokwi-ci/mcp-supportread 2026-10-08