Chiplab

> Simulate & validate firmware on virtual instances of real chips, straight from your AI coding agent — no hardware.

Chiplab is a hosted MCP service.

Your AI coding agent connects to it, uploads compiled firmware, runs it on a virtual instance of a real microcontroller, and reads back the UART output.

You don't drive the toolchain — your agent does.

We're building the next way to develop chips, in the open and early.

Today it runs `Hello world!` on STM32 and Nordic boards; a lot more is on the way — see **veecle.ai**.

Try it, poke at it, and tell us what you'd like to see.

Quickstart

1. Create a free account at **veecle.ai** (no credit card).

2. Connect your agent to the Chiplab MCP server.

3. `git clone https://github.com/veecle/chiplab && cd chiplab`, then tell your agent:

> *"Set up Chiplab and run the stm32f4-discovery example on it."*

Your agent reads AGENTS.md, installs what it needs, builds the firmware, uploads it, runs it on the virtual board, and reports `Hello world!` back from the chip's UART.

That's the whole loop.

Connect your agent

Chiplab is an HTTP MCP server at `https://chiplab.veecle.ai/mcp`.

Most clients take the standard `mcpServers` schema:

{
  "mcpServers": {
    "chiplab": {
      "type": "http",
      "url": "https://chiplab.veecle.ai/mcp"
    }
  }
}

On first use your client opens a browser to sign in.

To verify, ask your agent to call Chiplab's discovery/help tool with no arguments.

Claude Code

If you cloned this repo, the server is already configured via `.mcp.json` — Claude Code will prompt you to trust it.

Otherwise:

claude mcp add --transport http chiplab https://chiplab.veecle.ai/mcp

Claude Desktop / Cursor

Use the `mcpServers` block above in `claude_desktop_config.json` or `.cursor/mcp.json`.

VS Code

Same block in `.vscode/mcp.json`, but under a `servers` key instead of `mcpServers`.

Codex

TOML in `~/.codex/config.toml`:

[mcp_servers.chiplab]
url = "https://chiplab.veecle.ai/mcp"

Then sign in with `codex mcp login chiplab`.

How it works

The contract is framework-agnostic: your agent builds an ELF → uploads it → runs it on the target board → reads the captured UART output.

Runs return synchronously and are bounded to a fixed amount of virtual time.

This repo ships a ready-to-run example for every supported board, grouped by framework — `bare-metal` (Rust, vendor HAL), `embassy-rust` ([Embassy] async), `zephyr-os` ([Zephyr RTOS], C), `freertos` ([FreeRTOS], C), and `threadx` ([Eclipse ThreadX], C).

The full board × framework matrix is in **supported-boards.md**.

[Embassy]: https://embassy.dev

[Zephyr RTOS]: https://zephyrproject.org

[FreeRTOS]: https://www.freertos.org

[Eclipse ThreadX]: https://github.com/eclipse-threadx/threadx

Toolchain and build details live in each framework's directory (`examples//README.md` for humans, `AGENTS.md` for agents) — your agent finds them on its own.

Prefer building by hand?

Each framework README has the exact commands.

To run your own firmware, build an ELF for a supported board and ask your agent to upload and run it the same way.

Contributing

Adding a board example is the easiest way in: mirror an existing example for the same framework and add a row to supported-boards.md.

All conventions live in **AGENTS.md** and each framework's `AGENTS.md`.

New chip, OS, or peripheral support is server-side — [open a request][new-issue] instead of adding an example for an unsupported board.

[new-issue]: https://github.com/veecle/chiplab/issues/new/choose

Found a bug? Missing a chip? Tell us here.

This is Chiplab's public home — bugs, feature ideas, and chip/OS/peripheral requests all belong in [this repo's issues][new-issue].

Requests really do shape the roadmap — see veecle.ai/roadmap for what's planned, or come say hi on Discord.

License

MIT © 2026 Veecle GmbH.