Persona.js

The boundary I’d want to inspect in every WebMCP app is the receipt after a mutative step, not just the approval before it.Tool name, page/app context, inputs used, approval, result, and whether it can be undone. That’s what makes the action feel debuggable instead of magical.

I had been toying around with the idea of writing an internal tool for our implementation team to quickly spin up, configure and iterate on accounts with a promptable interface. Our platform is highly customizable and composable so this is typically a pretty heavy lift to even get to a demoable state for a customer, much less to a go-live state. Persona arrived at the perfect time and I was able to get it working within a day, and I expect it to start accelerating our implementation work immediately. WebMCP makes this extremely powerful. Haven't had to lean on the polyfill as we use Chrome, so I can't speak to that part, but I imagine there are plenty of people and companies out there with use cases similar to ours that this would work perfectly for even without that.

Persona looks polished yet flexible, especially with the no‑code theming and deeper dev hooks. Curious, when you tested it on sites like WordPress or Shopify, what was the biggest challenge in making the experience seamless?

That split is fair, and the server framework is genuinely where I'd want the real teeth. The part I keep snagging on is that the dangerous chain spans both halves. The client sees a getter fire, the server sees a mutation fire, but the step where one fed the other lives in the gap between them. We hit exactly this building agent tool-loops: every call looked safe on its own, the damage was in the ordering. Do you end up passing any call provenance across the seam, so the server side can see what the client already ran?

The WebMCP angle is what makes this feel more than another chat widget to me.The safety/usability detail I’d want as a builder is a clear tool-call preview: what page tool the assistant is about to use, what state it will change, and what the user can undo.For existing apps, the scary part isn’t adding chat; it’s letting an agent touch real UI flows without turning every action into a mystery. If Persona can make those side effects visible and reversible by default, it would lower the trust barrier a lot.

WebMCP-native is the part that grabs me. Most "AI chat widgets" just bolt a chatbox onto a page, but having the chat actually talk to your frontend through MCP feels like a much cleaner way to let the AI do real things instead of just answering FAQs.

That read-only vs mutative tagging plus HITL is exactly the right shape, thanks for the concrete demo. The bit I am chewing on is where the tag comes from. If the developer declares it, safety still rests on them classifying correctly, and a tool that looks read-only (a getter) can feed its result straight into a mutative call. Does the HITL gate reason about a chain that ends in a mutation, or approve per individual call? That chaining case is where I would expect intent to slip.

The framework-agnostic approach is what caught my attention - most chat UIs are React-first, which quietly locks your architecture. The WebMCP-native integration is the right bet as MCP becomes the standard interface layer for AI tools. Quick question: how does Persona handle auth context when the MCP server needs user-specific permissions? Does the host page manage that entirely, or is there a mechanism built into the library for passing tokens through?

The WebMCP-native angle is the part I keep thinking about, since you said a tool registration can invoke basically any JS function on the page. That cuts both ways. Once the agent can drive real UI, what stops it from firing a destructive or paid action it misread the user's intent on? Is there a scoping or confirmation layer for high-stakes tools, or is safety entirely on the developer to only register the safe ones? Curious how you draw that boundary.

The WebMCP-native angle is the part that got me, registering frontend tools so the agent drives your real UI instead of a headless browser feels way cleaner. For an existing React/Next app, how granular can you get about which actions you expose as tools? Congrats on shipping.

WebMCP support out of the box is a massive selling point, the biggest headache right now is avoiding massive token usage for simple frontend states. congrats for shipping @runtypical👏 qq. does the built-in polyfill handle older browser fallbacks gracefully, or is there a performance hit we should watch out for?

Hey Product Hunt 👋 I'm Nathan, cofounder at Runtype and one of the people who built Persona.Persona is the world's first AI chat library to natively support WebMCP. It's a framework-agnostic chat UI you can drop into any existing website or app to easily add AI to your product. Why we built itMost AI chat libraries assume you're starting from scratch on React. Persona is built for the rest of the internet: existing sites, mixed frontend stacks, proprietary CMSes, and teams that want a modern AI experience without rebuilding in React. Drop it in with no build step, theme the whole experience through config and the built-in editor, then ship it as a chat widget, a full-screen ChatGPT/Claude-style surface with artifacts, or something in between. It looks polished out of the box & you can make it pretty far down the path of customization with no code, but still gives developers hooks and plugins when they want to go deeper.It’s built in Vanilla JS so it can work anywhere - WordPress, Shopify Liquid, Static HTML sites, and more.The part we're most excited about: WebMCP 🧩Persona is the first Agent UI framework to natively support WebMCP, which just shipped in Chrome and has polyfills available for all other browsers. With WebMCP, you can register agent-facing tools directly in your frontend, which allows Persona-based agents to directly use your frontend app with much more dexterity & token efficiency than other approaches (headless browsers, DIY frontend tools, etc).If you already have a sophisticated web app, this can be a much faster path to enabling AI capabilities in your app vs building an entirely new backend. And since WebMCP tools can be hooked directly into frontend code, the experience feels much more like a “copilot” and less like a bolt-on, all the usual side-effects and UX are preserved while your app gets more capable.Some cool demos:Fullscreen Assistant → persona-chat.dev/fullscreen-assistant-demo.htmlSlides → persona-chat.dev/webmcp-slides.htmlCalendar → persona-chat.dev/webmcp-calendar.htmlMSPaint → persona-chat.dev/webmcp-paint.htmlWebMCP is maturing to the point where it makes sense to start building against it, and Persona makes that easy with a built-in polyfill.Open source, no lock-inPersona is MIT-licensed and open source. It's made by an AI platform company, but it's deliberately not coupled to Runtype. You deploy it on any framework and wire it to any SSE-based AI endpoint with a little glue code. Examples for popular frameworks like Flue, Eve, OpenAI Agents SDK, and more are in the repo along with docs your existing coding tools can use to implement it quickly.If you’re like to deploy a chat agent as quickly as possible, the CLI command:npx @runtypelabs/cli@latest persona init…will set you up with a WebMCP-capable chat agent on the Runtype platform in minutes.Who it's forBuilders adding an AI experience to something that already exists, without a rewrite and who want to benefit from us obsessing over the details of frontier AI experiences so they can just deploy them.Repo, docs, and examples: github.com/runtypelabs/personaWe'd love your feedback! If you've tried adding AI into an existing app, I'm curious what was hardest: picking the right framework, standing up a new backend, wiring up the tools, building out the right evals, or trusting what the AI actually does. Happy to go deep on WebMCP in the comments.