Launching today
Persona.js
Add WebMCP-native AI chat to any Frontend
254 followers
Add WebMCP-native AI chat to any Frontend
254 followers
Persona is a lightweight, open-source AI chat UI library that embeds into any website, from modern apps to static HTML. Unlike React-based chat frameworks, Persona is framework-free, backend-agnostic, and WebMCP-native, so your assistant can discover and execute tools exposed by the parent page. Add streaming chat, voice, theming, and interactive copilot experiences without rebuilding your frontend or writing bespoke APIs.
Persona.js
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 it
Most 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.html
Slides → persona-chat.dev/webmcp-slides.html
Calendar → persona-chat.dev/webmcp-calendar.html
MSPaint → persona-chat.dev/webmcp-paint.html
WebMCP 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-in
Persona 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:
…will set you up with a WebMCP-capable chat agent on the Runtype platform in minutes.
Who it's for
Builders 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/persona
We'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.
@runtypelabs @runtypical The WebMCP bet is the interesting part beyond the chat UI. Honest question: is WebMCP an actual emerging standard that browsers and agents will converge on, or your own convention for now? The payoff (any agent reading the page's exposed tools) only lands if it isn't Persona-only. If a future Claude or ChatGPT browser extension can read those same tool registrations, that's huge; if it's a closed loop it's a really nice chat widget. Where does it sit today?
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.
Persona.js
@dipankar_sarkar yes! Similar to the protections that MCP tools typically have in chatbots and harnesses today, WebMCP tools can be tagged based on whether or not they are 'read-only' or mutative/potentially destructive, and Persona (in collaboration with the agent backend) can support HITL (Human-in-the-loop) approval flows for those actions.
This can be seen on demos like these:
https://www.persona-chat.dev/approval-demo.html (also has a great example of a Persona plugin)
https://www.persona-chat.dev/webmcp-demo.html ("Add to cart" requires approval)
On the general topic of WebMCP security, both Persona and Runtype have adapted Google's best practices around WebMCP security, which you can read here:
https://developer.chrome.com/docs/agents/security
https://developer.chrome.com/docs/ai/webmcp/secure-tools
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?
Persona.js
@vikramp7470 great question - the polyfill is both lazy-loaded and defensive; it won't waste any resources at all if WebMCP is already discovered on the page, even if it's from another polyfill. In fact, the entire initial page weight of Persona is only about ~15kb, to minimize the performance hit when embedding.
@runtypical Great to know, appreciate the transparency on performance...
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.
Persona.js
@i_sanjay_gautam Thanks! WebMCP tool registrations can theoretically invoke any javascript function living on a page, as well as be added as a decorator to existing HTML forms.
For frameworks like Next.js or React you can use plugins to easily hook into your existing actions and expose them as WebMCP, although I'd always encourage folks to intentionally design your tools around the needs of the agents - I personally love Arcade.dev's guide on MCP tool design, and I think the same principles apply to WebMCP!
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?
Persona.js
@galdayan Great question! There are essentially two paths, which you can blend together based on where the auth checks already are.
1) Handling auth context on the API side. Usually you are already streaming LLM / AI framework calls through the backend so the state of the user is already available. Persona has examples of using a proxy to do this in the repo as well.
2) Using WebMCP to respect the auth context automatically. Since the tools are being called on the frontend when you use WebMCP, you can pass the signed in user's identity as part of the existing function calls. If your app's frontend works with signed in context today, you might not need additional backend work.
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.
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.