Widgetry
2026 · SaaS in production
ChatGPT, Claude, VS Code and Goose already render interfaces inside the conversation: a board, a few figures or a chart instead of a paragraph. That is the MCP Apps standard, and doing it by hand means writing an MCP server, bundling an HTML view, speaking a postMessage protocol, setting a CSP and deploying it. Widgetry saves you all of that: you pick a template, adapt it, see it exactly as the chat will show it and take it to your own MCP server.
The first version served the widgets from an MCP server of Widgetry’s own, and the same day I turned it around. A widget locked inside my service is not much use: it has to live in each person’s server, next to their tools and their data. So the main way out is taking it with you, and Widgetry’s endpoint stayed as the way to try a widget without a server of your own. Then came the other half: your agent makes the widgets for you, through that same endpoint, with the same permissions you would have on the web.
Underneath it is TanStack Start over Postgres, with a service layer where every rule lives, so the web, the API and the MCP endpoint apply the same ones without repeating them. It runs on Cloud Run, in its own schema of the micropodcast aggregator’s database. The landing page is public; for everything else you sign in with Google.
Part by part
Type and design, kept apart
A widget is a Liquid template with its CSS and the schema of the data it renders, and when markup is not enough, an optional script with libraries from a closed catalogue at pinned versions: three.js, GSAP, d3 and Chart.js. There are thirteen types, from a board to a 3D globe, and twenty built-in designs: the house one, five classics and fourteen inspired by well-known brands, taking only their colours, radii and typographic character, never their logos. Type and design are separate axes: the template only reads a set of tokens that each design sets, so any type works with any design. And a designer to make your own, starting from a built-in one.
See what the chat will see
The editor lets you change the data, the markup, the styles, the script and the schema, checks the data against that schema and saves on its own. The preview does not imitate a chat: it is a real MCP Apps host that speaks the same protocol, in light and dark. It even blocks the same images. Every widget declares which origins it may load them from, and that goes into the resource's CSP and into the document's own, because before that a photo looked fine in the editor and arrived broken in Claude.
Take it to your server
A widget leaves in one of two ways. The default is to link it: your MCP server reads the published widget from its URL with a read-only key and a one-minute cache, so whatever you publish reaches it without a deploy. The other is to download the HTML document and the manifest, with the tool and its CSP, for anyone who would rather not depend on Widgetry. Both snippets that register the widget are tested with the official TypeScript SDK on a separate server, and if the SDK changes they get tested again.
An agent does what you do
One MCP endpoint, and the credential decides the organization and the tools. There are fifteen: eight that read, for anyone (starters, widgets, designs, the export), and seven that write, for whoever may write, which create, edit, publish and delete widgets and designs the way a person does on the web. Chats like claude.ai come in with OAuth and your account; coding agents and scripts, with an API key. Behind it there is Google sign-in, organizations with owners, editors and viewers, and invitations. Members, invitations and keys stay on the web on purpose: a key created by an agent would end up written into a conversation.