ImpressPress Dev Sandbox (dev.impresspress.org)

Inspiration

Wouldn't it be cool if you could build a whole website by pointing your agent at a page and saying "build me a shop"? No hosting provider to sign up for, no vibe-coding platform charging its own fees, no setup. We already have a capable agent in the browser — so let it do the work right there. One URL, one login, and the agent has everything it needs.

What it does

Open dev.impresspress.org in a browser whose agent supports WebMCP and sign in with the credentials shown on the page. The page hands your agent a small set of tools, and from there you just talk:

• Build the frontend — the agent writes the pages; every save is live in a preview next to the chat.
• Build the backend — the agent scaffolds a Rust "block", compiles it in the browser, and it's live within a minute. No toolchain, nothing uploaded anywhere.
• Stock a shop — products, prices and offers through the same tools, so a visitor's own agent can browse and buy.
• Undo anything — every change is a numbered generation you can roll back to.
• Export — download the finished site as a folder that runs from any static web host.

Everything runs inside a service worker in your browser tab. There is no server behind it, and nothing leaves your machine.

Why this is a strong fit for WebMCP

Building a website is a job where the agent needs the site's own capabilities — write this file, compile this block, publish this product, roll that back — not a generic browser. WebMCP lets the page hand exactly those capabilities to the agent as typed tools, with the site's own login behind each one. And because the whole thing runs in a service worker, the page can offer those tools even though there is no server at all.

How it makes a better experience

Before: to get an agent to build you a site with a real backend, you gave it a machine, an editor, a deploy pipeline and some credentials, then relayed its errors back and forth by hand.

Now: you open one page and describe what you want. The agent scaffolds a newsletter block, compiles it in the browser in about 48 seconds, creates three products and publishes their offers — in one conversation, while you watch it happen in the live preview. A compile error comes back to the agent as a file and line number, so it fixes its own mistake instead of asking you. When you're done, one click exports the site.

What people and agents can now do together

• A person describes a shop; the agent builds the pages, the Rust backend and the catalog, and the person sees it live as it goes.
• A visitor's agent can then use the tools the first agent created — for example, subscribe to the newsletter block it wrote an hour earlier — because compiled blocks publish their own WebMCP tools.
• Anyone can hand the exported folder to someone else, who runs it locally with a plain file server: the same shop, the same blocks, no accounts.

None of this needed a server, a cloud account or a toolchain install — which is what made it hard before.

How we implemented WebMCP

Every page registers its tools with document.modelContext.registerTool({ name, description, inputSchema, execute }). The tools aren't hand-written: each backend block declares typed HTTP endpoints, the runtime turns the ones marked as agent tools into a manifest (filtered to what the current visitor may call), and a small script registers one tool per entry — execute is a single same-origin fetch of that endpoint. The workspace page adds its own page-scoped tools (dev_* for files and blocks, shop_* for products), plus dev_compile_block and dev_export, which drive the in-browser compiler and the export download directly.

How we built it

Rust compiled to WebAssembly, running in a service worker with SQLite and a filesystem in the browser's storage. Code lives in "blocks" — isolated WebAssembly modules with declared capabilities — an open source project of mine, wafer.run. The in-browser Rust compiler is Rubrc (rustc and cargo compiled to WebAssembly), packaged as static assets and driven from a worker.

Challenges we ran into

• Rubrc is very new. Packaging its toolchain takes about an hour and 12 GB of RAM, so it's published as a release asset rather than built in CI.
• An in-browser compiler needs cross-origin isolation (COOP/COEP), which broke the live preview and the worker startup on a plain static host. The fix was to let the service worker set those headers for the whole site.
• Service workers see less of a request than a server does, so things like CSRF checks and "tools before the worker takes control" needed real fixes.
• Keeping it safe: agent-written blocks only get their own tables, storage and settings, are probed before activation, and the previous version stays live if a compile fails.

Accomplishments that we're proud of

It works end to end: an agent scaffolds a block, compiles it in the browser, a visitor's agent discovers and calls the new tool, and an export of the site boots the same shop on another server. It's also reasonably fast — a block compiles in under a minute, page edits show up in a few hundred milliseconds, and the exported site boots in about three seconds.

What we learned

A lot about what browsers let a service worker do. And that an agent is an unforgiving user: every refusal has to come back as a clear, structured message, or it just retries the same mistake. Tool descriptions that say exactly what a tool does — and what side effects it has — improved the agent's success rate more than anything else.

What's next

It is still very much a MVP, need to test more and get faster compiles, clearer diagnostics for the agent, and export straight to hosts like Cloudflare. Mostly: get it in front of people and hear what they want to build.

Built With

• cloudflare
• opfs
• playwright
• rubrc
• rust
• service-workers
• sqlite-(sql.js)
• wasmi
• webassembly
• webmcp