Show HN: Agent MCP Studio – build multi-agent MCP systems in a browser tab
agentmcp.studioI built a browser-only studio for designing and orchestrating MCP agent systems for development and experimental purposes. The whole stack — tool authoring, multi-agent orchestration, RAG, code execution — runs from a single static HTML file via WebAssembly. No backend.
The bet: WASM is a hard sandbox for free. When you generate tools with an LLM (or write them by hand), the studio AST-validates the source, registers it lazily, and JIT-compiles into Pyodide on first call. SQL tools run in DuckDB-WASM in a Web Worker. The built-in RAG uses Xenova/all-MiniLM-L6-v2 via Transformers.js for on-device embeddings. Nothing leaves the browser; close the tab and the stack is gone. The WASM boundary is what makes it safe to execute LLM-generated code locally — no Docker, no per-tenant container, no server.
Above the tool layer sits an agentic system with 10 orchestration strategies:
- Supervisor (router → 1 expert) - Mixture of Experts (parallel + synthesizer) - Sequential Pipeline - Plan & Execute (planner decomposes, workers execute) - Swarm (peer handoffs) - Debate (contestants + judge) - Reflection (actor + critic loop) - Hierarchical (manager delegates via ask_<persona> tools) - Round-Robin (panel + moderator) - Map-Reduce (splitter → parallel → aggregator)
You build a team visually: drag tool chips onto persona nodes on a service graph, pick a strategy, and the topology reshapes to match. Each persona auto-registers as an MCP tool (ask_<name>), plus an agent_chat(query, strategy?) meta tool. A bundled Node bridge speaks stdio to Claude Desktop and WebSocket to your tab — your browser becomes an MCP server.
When you're done, Export gives you a real Python MCP server: server.py, agentic.py, tools/*.py, Dockerfile, requirements.txt, .env.example. The exported agentic.py is a faithful Python port of the same orchestration logic running in the browser, so the deployable artifact behaves identically to the prototype.
Also shipped: Project Packs. Export the whole project as a single .agentpack.json. Auto-detects required external services (OpenAI, GitHub, Stripe, Anthropic, Slack, Notion, Linear, etc.) by scanning tool source for os.environ.get(...) and cross-referencing against the network allowlist. Recipients get an import wizard that prompts for credentials. Manifests are reviewable, sharable, and never carry secrets.
Some things I'm honestly uncertain about:
- 10 strategies might be too many. My guess is most users only need Supervisor, Mixture of Experts, and Debate. Open to data on which ones actually pull weight. - Browser cold-starts (Pyodide warm-up on first load) are a real UX hit despite aggressive caching. - bridge.js is the only non-browser piece. A hosted variant is the obvious next step.
Built with Pyodide, DuckDB-WASM, Transformers.js, OpenAI Chat Completions (or a local Qwen 1.5 0.5B running in-browser via Transformers for fully offline mode). ~5K lines of HTML/CSS/JS in one file.
Genuinely curious whether running this much LLM-generated code in a browser tab feels reasonable to you, or quietly terrifying.
Pretty cool, I’m excited to try this.
The WASM boundary as a security primitive is underappreciated most people reach for containers without asking whether the threat model actually requires a persistent process. On the 10 strategies question: Supervisor and Mixture of Experts will cover 80% of real workloads in my experience, with Debate and Reflection worth keeping as the next tier since Debate surfaces assumptions single-agent pipelines miss and Reflection catches compounding errors cheaply. The part I would stress test is the export-to-Python parity keeping browser prototype behavior identical to the deployed artifact is a hard problem, and curious how you are handling edge cases where Pyodide’s stdlib coverage diverges from CPython.
Yes, keeping extra eyes on the export to python feature... There may be edge cases that I haven't crossed yet, but will plan on resolved as many as possible.
Multi-agent + MCP in a browser tab is a clean demo surface. The question I'd ask: does the studio represent agent topology as data (so you can serialize / version/diff it) or is it implicit in the UI graph? We found the former matters a lot the moment you want to test the same workflow against two different models, or roll back a change someone made in prod.
It is serialized, every aspect of the agent layer and tool layer. I added an export and import feature... Take a look at the json
Great curious to try it out. Have you posted on Linkedkin as well ?
I have not posted on linkedin yet, will shortly after some feedback. Feel free to share it with your network!!
[dead]