Persona.js

Add WebMCP-native AI chat to any Frontend

Open Source

Developer Tools

Artificial Intelligence

Visit WebsiteSee on Product HuntGithub ⧉

WebMCP native is a smart move - feels like the right time to build on that protocol instead of rolling custom websocket solutions. Quick question: does this work cleanly with SSR frameworks like Next.js or Nuxt, or is it client-side only for now?

The WebMCP bet makes sense and drop-in on existing sites looks like the unlock! One thing we keep hitting building agents - the token-efficiency win can flip once a page exposes 20+ tools, since every schema rides in context each turn. As far as I understand Persona could send the model the full tool list or filter to a relevant subset first to decide if the headless-browser comparison holds at scale. Anyways, congrats on the great product

How does tool discovery work safely, like can the page expose only certain actions and require a user confirmation before anything runs?

Active-tools-reflecting-app-state is a cleaner answer than I expected, since the menu shrinks with the app instead of sitting wide open. The thing I'd watch from building agent loops: that same liveness means a tool the model planned to call two steps ago can quietly vanish when state changes under it, so a half-formed plan goes invalid mid-run. Do you surface that disappearance back to the model as a signal it can re-plan on, or does the call just fail when it reaches for the tool?

framework free + webmcp native is a smart bet 👏 the standard is gonna matter alot

Protected params is the one that moves the needle for me, taking the value out of the model's hands beats asking it to behave. The gap I'd still watch: that locks the WHAT, but the model still picks WHICH tool and WHEN off whatever a prior getter handed it. We hit a loop where every arg was clean but a poisoned read steered the model to fire a legit mutation at the wrong moment. Do you scope which tools are even available by app state, or does the model always see the full set?

This is great, just at the right time. This could make chat widgets as easy to add to existing websites as including a new Google Font or FontAwesome. And the WebMCP is great so other agents can use the site. Makes it extremely useful. Quick question, can you set up token limits, per visitor/user?

the "rest of the internet" framing is the right one. most ai chat libraries assume you're shipping a new react app on a clean slate. that's not where 90% of the actual web lives. shipping into someone's existing wordpress, a 2018 next.js install, or a php shop is where real adoption happens.

webmcp-native is the part i keep thinking about. once an agent can actually act inside your ui through a standard protocol, the chat stops being a help widget and starts being an interface. curious how you're thinking about discovery. letting other agents know what a persona instance can do without each integration being a custom contract.

The "discover and execute tools exposed by the parent page" part is the interesting bit, and also where I'd want to hear your boundary story. Once the in-page assistant can call real parent-page tools, the chat input becomes an execution surface: a pasted block of text, or third-party content rendered in the thread, can try to talk the model into calling a sensitive tool (submit, delete, pay) the user never actually asked for.

Does the host page get a way to mark which exposed tools are model-callable vs require an explicit user gesture, and is there anything in between "tool is discoverable" and "tool just ran"? That separation is what would make me comfortable dropping this into a page that already has real write actions.

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.