Roaster
EN / RU
Agent MCP Studio

Agent MCP Studio

I 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. https://www.agentmcp.studio Genuinely curious whether running this much LLM-generated code in a browser tab feels reasonable to you, or quietly terrifying.

Design BOTH · stealthtsdb
N/A
Revenue not available

AI Analysis

Analysis coming soon.

Similar Products

Design
A factory simulator game built on Spreadsheets

A factory simulator game built on Spreadsheets

I would say this is the real factory simulator game haha

Revenue N/A
Design
Housecat.com

Housecat.com

Hey we are Housecat. I've spend the last 15 years building dev tools at Heroku, Convox (YC S15), and Segment. Dev tools have gotten insanely good over the decades, now we're working to level up productivity tools for everyday work. Housecat is an email inbox running on an single-tenant agent computer with a durable workflow engine and connections to common tools for day-to-day work. My primary workflow with the product is for customer support: get a support email, trigger a triage process, open a GitHub issue, spin up a coding agent to fix it, and update the customer along the way. All from the same UI and sandbox. We've experimented with lots of different approaches to new workspace tools, and learned that many people still need a great GUI. We've landed on the email inbox as a very familiar and permanent surface and are building tools and automations directly inside it. Under the hood every user gets their own single-tenant sandbox VM and persistent SSD on exe.dev. User connections to Google, Slack, GitHub, etc. are managed in an external service so the VM and agent are subject to external governance and don’t have direct access to secrets. Durable workflows are built on DBOS.dev. Running interactive and deterministic workflows directly inside an email couldn’t feel more different than chatting about emails in Claude.app. The app is built on HTMX, Unix, Go, and SQLite. The app is source available to users and the Linux VM is fully open for a user and their agent to poke around. You can try it out at https://home.housecat.com/beta. It requires a Google / Gmail connection for the email app, which you can revoke any time. We'd love to share more and learn how the community here is managing email, agentic chat, and custom workflows for their work.

Revenue N/A
Design
Designing a Static Site Generator for iPhone

Designing a Static Site Generator for iPhone

Show HN: Designing a Static Site Generator for iPhone

Revenue N/A
Design
Computable

Computable

Hey we are Computable. We spent years building trading infrastructure at Jump Trading and Coinbase. From that point of view, compute looks like energy markets before 2000: everything trades through private bilateral leases, there’s no visible price, and nothing can be resold. The same H100 rents at a 2x spread depending on who’s asking, and once you sign a 24-month lease, it can never change hands. So we built a market for GPU nodes, sold by the calendar week. Here are three things you can do on it that you can’t do anywhere else: - Buy exactly the weeks you need. Three nodes for the last two weeks of October means you pay for those two weeks and walk away when the run is done. You don't have to commit to 6-24 months, and there's no flexibility premium. - Sell back what you don’t use. If your plans change, unused weeks turn back into cash: we keep a market quote posted on every position, so there’s always a price to hit. - Buy (or sell) the future. Lock January in July at a price you set, so the cost of a future run is known before another 40% H100 rate jump makes it not. The first auction is live now at https://market.getcomputable.com: a block of nodes, August through the end of January. Bidding closes July 31. The bids are sealed. You bid how many nodes, which weeks, and your price. Every clearing price gets published after settlement, because nobody knows what a GPU week is worth and we want the prints to exist in public. Happy to go deep in the comments on anything, including the clearing mechanism, which is a packing problem and was fun to design!

Revenue N/A
Design
A canvas-based note taking and organizer app

A canvas-based note taking and organizer app

So I've been working on this app for a very long time now. Started off by wanting an app that separates long form notes from short form notes visually and keeps everything organized on a canvas. The app features: -Sticky notes for quick, small notes and A4 notes for long form documents -A quick mode that uses local storage to quickly open the app and jot down a thought on the canvas -A PDF export option that exports your notes into 3 custom designed PDF styles -Visual hierarchy to replicate file structure instead of a linear fashion, where your files are notes, stacks are folders and labels are names for your folders Would love to continue working on this app if you guys like the concept.

Revenue N/A

Quick Facts

Category
Design
Audience
BOTH
Founder
stealthtsdb
Revenue data
Unknown

Share