Simten — Hardware design in TypeScript

Drive Simten from any MCP-compatible AI assistant — build, simulate, and verify circuits from your terminal

Simten ships an MCP server (@simten/mcp) that any MCP-compatible AI assistant can drive — Claude Code, Codex CLI, Gemini CLI, Cursor, and others. You talk to your assistant in the terminal; it writes TypeScript circuit files, pushes them to a live viewer in your browser, and runs simulations and verification — so you watch the circuit take shape on a canvas as it's built.

It's a standard stdio MCP server, so the tools below are the same whatever client you point at it. The examples on this page use Claude Code as the reference client.

What it looks like

You run your assistant in the terminal. When you ask it to build something, it:

Writes the TypeScript circuit definition to a file
Pushes it to a live viewer in your browser — the circuit appears on the canvas instantly
Runs a simulation, or a self-checking testbench, to confirm it behaves correctly

The browser is a viewer: the assistant pushes circuits, waveforms, and test results to it for display. It is one-way by design — the page shows what was built and sends nothing actionable back (see Security). You drive the conversation from the terminal, where your assistant already lives.

Setup

1. Install a client

If you don't already have one, install an MCP-capable assistant. Any of these work; the rest of this page uses Claude Code.

2. Add the MCP server

Pick your client:

$ claude mcp add simten npx @simten/mcp

This registers the Simten MCP server with your assistant, which now has access to the circuit design tools.

3. That's it — the viewer opens itself

When the assistant calls show_circuit, the MCP serves a small bundled editor from localhost and opens it in your browser automatically. Because the page and its WebSocket share a single localhost origin, there's no "Local Network Access" prompt and it works in every browser (including Safari). You don't need to visit simten.dev.

Available tools

Once the MCP server is registered, your assistant has access to these tools:

Tool	What it does
`get_grammar`	Return the `circuit()` builder API (inputs/outputs, nodes, connect) with worked examples.
`list_components`	Return the full catalog of stdlib components — each with its ports and constructor options (e.g. `Register({ width })`).
`get_verify_api`	Return how to write a `.verify.ts` testbench — the `simulate()` stepper API, `verify.exhaustive`/`verify.check`, `declareOracle`, and worked examples.
`show_circuit`	Push a circuit file to the browser viewer and open a live preview. Watches the file for changes.
`check_circuit`	Validate circuit source (syntax, semantic, type, structural) without running it.
`simulate_circuit`	Compile and simulate; return signal traces and the steady-state cycle. Observation only — shows what the circuit does, not whether it's correct.
`verify_circuit`	Run a self-checking `.verify.ts` testbench at a declared oracle tier. This is the correctness gate (see Verifying circuits).
`read_waveform`	Query a VCD waveform for specific signals over a cycle window.
`run_on_fpga`	Build and run the circuit on a connected FPGA board.

get_grammar, list_components, and get_verify_api exist because clients cap an MCP server's instructions and each tool description at 2 KB — too small to inline the circuit API, the component catalog, or the testbench-writing guide. The assistant calls these on demand to get the authoritative part names, signatures, and simulate() API rather than guessing.

How the connection works

The MCP server runs locally alongside your assistant and serves two roles:

MCP tool provider — the assistant calls tools via the standard MCP protocol (stdio transport).
Local studio — a single HTTP + WebSocket server on localhost:19847 serves the bundled viewer and hosts the socket the viewer connects back on. The page and the socket share one origin, which is what sidesteps the browser's Local Network Access block.

When the assistant calls show_circuit (or pushes traces / test results), the data flows one way to the viewer for display. The viewer sends back only a boolean render acknowledgment — there is no channel for the page to drive the assistant or read host state.

Assistant (terminal)
    ↕ MCP (stdio)
MCP Server (local)
    ↓ WebSocket push
Browser viewer

Session & security

Loopback only — the server binds 127.0.0.1, so it isn't reachable from your network.
Per-process token — a fresh token each time the MCP starts, handed to the viewer via the URL fragment; connections without it are rejected.
Origin allowlist — only localhost-origin browser connections are accepted, so a web page you happen to be visiting can't open the socket.
Viewer-only — the studio accepts nothing actionable from the browser; untrusted page data never reaches a tool result.
Auto-reconnect & cache replay — the viewer reconnects automatically and receives the most recent pushed circuit on connect; each tab is its own session.

Example workflow

You: "Build me a 4-bit counter with a hex display"

The assistant:

Writes the circuit: Register + Adder + Constant + HexDisplay
Calls show_circuit — the circuit appears in your browser viewer
Calls simulate_circuit (or verify_circuit) to confirm it counts correctly
Replies in the terminal: "I've built a 4-bit counter. Click play to watch it count from 0 to F."

You: "Can you add a reset button?"

The assistant:

Edits the circuit file it already wrote
Adds a Switch and Mux for reset logic
Calls show_circuit again — the viewer updates live, and you see the reset switch appear

Running without an assistant

The app works without any AI assistant. You can:

Write circuit code directly in the editor
Explore the interactive blog posts
Embed circuits in your own React app

An assistant is an enhancement, not a requirement. The MCP server adds an AI tutor to the experience, but all the tools and content work standalone.

MCP Integration