Open Reader

MCP Apps: Primitives, discovery, and the Future of Software - Pietro Zullo, Manufact, Inc

completed 28:54 Jul 05, 2026 Watch on YouTube

Current Status

completed

Video ID

sAOBXCDiDOs

RAG / Chat

Enabled
MCP Apps: Primitives, discovery, and the Future of Software - Pietro Zullo, Manufact, Inc
Description

Everyone in this room knows what MCP is, but I am sure not many people know what MCP Apps are, how they work, how to build them and distribute them. By the end of this talk you'll know everything you need to join the race! MCP Apps are not just MCP servers with a UI bolted on. They're a full interaction layer: bidirectional, stateful, rendered by the host, with the model and the UI sharing live context. This talk is structured around **What MCP Apps actually are.** The architecture: how an App is declared via `ui://` resources, how the host renders it in a sandboxed iframe, how the JSON-RPC-over-postMessage transport works, and how state flows between the model and the UI. **The primitives that make them real.** `ui/update-model-context`, the App pushing live state into the model's context window without a user message. `ui/message`, the App talking back into the conversation unprompted. App Tools, the model calling into the App's registered tool surface. **A showcase of MCP Apps shipping today.** Concrete demos, not slides about what's possible. What early builders have figured out, what's hard, and what the interaction patterns look like in practice. **Distribution and discovery.** How the stores work, how to submit, what the surface looks like across hosts, and what the install/discovery UX actually means for builders. **Why companies will need to move** Any product that is used by humans through a UI will need an MCP App version, or it gets bypassed by all the people that are getting more and more used to do everything through agents. As long as there are people using these systems, MCP Apps is the answer. For the rest, there is MCP. Speakers: - Pietro Zullo (Manufact, Inc): Pietro is the co-founder of Manufact (YC S25). Manufact created and maintains mcp-use, an MCP framework with more than 8M downloads across PyPI and npm, one of the leading MCP development frameworks today. Manufact is the cloud for MCP. You can think of Manufact / mcp-use as Vercel

Summary

Generated by claude-sonnet-4-5

At-a-Glance

  • Verdict: Watch fully
  • Core thesis: MCP apps (MCP servers that return interactive UI components instead of JSON) are the future of software distribution, and now is the critical moment to publish because major LLM clients (ChatGPT, Claude, Cursor) have opened self-serve submission stores with dynamic discovery that organically matches user intent to MCP apps.
  • Why it matters: Dynamic discovery means billion+ active LLM users can find your product organically when they express intent in chat—the model automatically searches MCP registries and installs the right connector. This is a fundamental shift in software distribution GTM.
  • Best use: Watch fully for operator-level understanding of MCP app primitives (streaming UI updates, bidirectional communication, privacy-preserving patterns), store submission tactics, and why being in MCP stores before competitors is strategically critical.

Executive Summary

Pietro Zullo (co-founder, ManiFact) argues that MCP apps—MCP servers that return interactive UI widgets in sandboxed iframes instead of JSON—represent how software will be used and distributed going forward. MCP launched in 2024; by late 2025 ChatGPT and Claude quietly opened MCP stores with one-click install; in January 2026 MCP UI became MCP apps (official protocol extension). Critically, these stores now accept self-serve submissions at scale, and Claude already implements dynamic discovery: when a user expresses an intent the model lacks tools for, Claude searches the MCP registry and installs the best-fit connector automatically. This means products in MCP stores capture organic intent from billion+ active users without traditional distribution.

MCP apps enable rich bidirectional patterns: streaming UI updates as the model generates tool arguments (e.g., rendering a live video preview via Remotion or SVG diagrams as tokens stream in), sending follow-up messages from the UI to the model, calling other tools from widget buttons, and privacy-preserving output splitting (show sensitive data in the UI iframe but send only sanitized summary text to the model). Clients differ: Claude prompts user confirmation for UI-triggered messages; ChatGPT auto-sends them. Supported clients include ChatGPT, Claude (web/desktop), Cursor (agent/chat), VS Code, and more.

Distribution is the unlock: ChatGPT, Claude (team/enterprise), and Cursor now have self-serve submission forms. Submission requires remote MCP server with proper tool annotations, authentication declaration, test cases/prompts, and compliance checks (partly automated, partly manual). ManiFact Cloud automates readiness checks and generates submission artifacts (screenshots, test cases). Once accepted, apps appear in directories (chatgpt.com/apps, Claude connectors, Cursor directory) with shareable one-click install URLs—no more sharing JSON config files. Dynamic discovery is live on Claude and expected soon on ChatGPT.

ManiFact provides open-source SDKs (8M+ downloads, 10k GitHub stars) abstracting official MCP SDKs, an open-source inspector for local testing, and ManiFact Cloud for deploying from GitHub, running evals, and publishing checks. MCP-use (their SDK) lets developers define tools and return React components as widgets, auto-registering UI resources and compiling to HTML/CSS. Pietro's personal workflow example: pull meeting notes from Granola MCP, create Linear tickets via Linear MCP, have agent open PRs in codebase via Claude Code, close tickets—all context-shared across connectors. This integrated workflow is his daily driver and a core buying criterion for products.

Key Takeaways

  • Claim: MCP apps are MCP servers that return interactive UI components (sandboxed iframes) instead of JSON, enabling richer user experiences and bidirectional communication between UI and LLM host. | Evidence: MCP apps became official protocol extension in January 2026; UI widgets display inline/fullscreen/picture-in-picture; examples include Excalibur MCP streaming mermaid diagrams as tokens arrive, Remotion MCP rendering live video previews, and ManiFact analytics MCP showing visual dashboards instead of JSON logs. | Caveat: Client support varies: Claude prompts user to confirm UI-triggered messages; ChatGPT auto-sends them. Some clients (e.g., older MCP-only clients) ignore widgets and need fallback JSON output. MCP-use SDK provides primitives to detect client support and conditionally return widgets. | Implication: Ken should understand MCP apps as the next layer of agent UX—not just tool calls returning text, but interactive components that users manipulate while the model reads state. This matters for designing agent products, evaluating vendor MCP implementations, and deciding whether to build MCP apps vs. traditional integrations. | Timestamp: 00:00-04:30
  • Claim: ChatGPT, Claude, and Cursor have opened self-serve MCP store submissions, and Claude already implements dynamic discovery: when a user expresses intent the model lacks tools for, Claude searches the MCP registry and auto-installs the best connector. | Evidence: Claude team/enterprise accounts can self-submit via form (launched ~2 weeks before talk); ChatGPT accelerated acceptance speed; Cursor has submission form. Claude dynamically searches MCP registry when assigned tasks without matching tools; ChatGPT expected to follow soon. Pietro: 'More than a billion active users… through the intelligence of the model, the model will choose what is the best connector. If you're there… this is going to be a huge wave of intent.' | Caveat: Dynamic discovery currently live only on Claude (not yet ChatGPT/Cursor). Submission is partly manual/partly automated with required test cases, authentication checks, and compliance review; acceptance speed varies by client. Claude submission currently limited to team/enterprise accounts. | Implication: This is a GTM unlock: being in MCP stores before competitors means capturing organic user intent at scale without traditional marketing spend. Ken should prioritize MCP store submissions for any product with API/tool potential, especially in productivity/dev tools categories where Claude/ChatGPT users are concentrated. Dynamic discovery = search distribution layer for software. | Timestamp: 18:00-22:30
  • Claim: MCP apps enable privacy-preserving patterns: show full sensitive data in the UI iframe but send only sanitized summaries to the LLM, keeping private info client-side. | Evidence: Tool returns list of outputs: one structured output populates the widget (e.g., full user profile card with private details), separate text output sent to model (e.g., 'User is seeing their private information in the widget above'). Pietro: 'Common pattern… show the full information in the UI, instruct the model with a text output… the model won't see the data you display in the UI unless you choose so.' | Caveat: Pattern requires developer discipline to split outputs correctly. No enforcement mechanism prevents accidentally sending private data to model output. UI iframe is sandboxed but still runs in user's LLM client context (not fully isolated server-side). | Implication: This solves a major MCP adoption blocker for enterprises and regulated industries (finance, healthcare). Ken can pitch MCP apps to privacy-sensitive prospects by showing they can expose tools to LLMs without leaking PII into model provider logs. Also useful for competitive moats: show rich UI to users while giving model only high-level instructions. | Timestamp: 13:30-15:00
  • Claim: Streaming UI updates let MCP apps render incremental tool inputs as the model generates arguments token-by-token, enabling real-time interactive experiences like live diagram drawing or video preview generation. | Evidence: Excalibur MCP demo: Claude streams mermaid syntax tokens into canvas, UI updates live with each token. Remotion MCP demo: React video rendered in widget as model streams video generation arguments. Pietro: 'You can take those partial inputs and update the UI incrementally… one of the coolest demos of MCP apps uses exactly this pattern.' | Caveat: Requires UI framework that handles partial/streaming data (React with state updates works well). Not all MCP clients stream tool arguments incrementally with same fidelity. Performance depends on UI complexity—heavy rendering (e.g., video) may lag. | Implication: Streaming UI patterns unlock 'co-creation' UX where users watch the model build artifacts in real time (diagrams, videos, code visualizations). Ken should explore this for content generation, design tools, data visualization products. Also useful for agent observability: show users what the agent is thinking/building as it works. | Timestamp: 09:30-11:00
  • Claim: Submission to MCP stores requires remote MCP server (not local), proper tool annotations/arguments, authentication declaration, test cases/prompts, and compliance checks; ManiFact Cloud automates readiness validation and artifact generation. | Evidence: Submission process: link remote server, providers scan tool annotations and authentication, developer provides test cases/prompts, partly manual/partly automated review, accept/reject decision. ManiFact Cloud 'vets your app to make sure it's ready… we check and try to do all the checks those clients will do… generate submission artifacts like screenshots and test cases.' | Caveat: Acceptance speed varies: ChatGPT 'speeding up a lot,' Claude 'going to take maybe a bit more for now' (as of talk date). Manual review component means no guaranteed acceptance timeline. Requirements differ slightly across ChatGPT/Claude/Cursor stores. | Implication: Ken should budget 1-2 weeks for submission process (faster for ChatGPT, slower for Claude). Use ManiFact Cloud or similar tooling to pre-validate before submission to avoid rejection cycles. Prioritize clean tool annotations and robust test cases—these are the most common rejection reasons. Remote hosting is non-negotiable (no local-only MCP servers in stores). | Timestamp: 19:00-21:00

Detailed Brief

MCP apps: Architecture and bidirectional communication primitives

  • Claims: MCP apps are MCP servers that return UI resources (sandboxed iframes) instead of JSON strings when tools are called.; Bidirectional communication channel exists: UI can send messages to host (model), host updates UI based on tool arguments.; UI is sandboxed iframe; developer can put 'almost whatever you want' inside.; UI resources declared at initialization; tool populates UI arguments at call time; client renders widget.
  • Evidence: Demo: model streams text, calls tool, tool returns widget underneath; user sees structured UI (e.g., article cards) instead of JSON wall of text.; setState primitive: from widget, call setState to update model's knowledge of UI state (e.g., 'nothing selected' → 'item 3 selected'); model then aware of user interaction in UI.; sendFollowUpMessage primitive: button in UI (e.g., 'learn more about Trailblazer Pro') sends message to chat; Claude shows message in input box for user confirmation, ChatGPT auto-sends and starts streaming response.; Streaming updates: tool receives partial inputs as model generates arguments token-by-token; UI updates incrementally (e.g., Excalibur MCP renders mermaid diagram as syntax streams in, Remotion MCP renders video preview live).; callTool primitive: from UI widget, trigger additional tool calls to fetch more data (e.g., button click calls another tool to get related info).; Output splitting: tool returns list of outputs—one for widget (full data), separate text output for model (sanitized summary). Example: show full user profile card in UI, tell model 'User is seeing their private information in widget above' without exposing PII to model.
  • Caveats: Client behavior differs: Claude prompts user to confirm UI-triggered messages; ChatGPT auto-sends. Not all clients handle streaming inputs with same fidelity.; Older MCP-only clients (non-MCP-app) simply don't render widgets; need fallback JSON output if widget not shown. MCP-use SDK provides detection to conditionally return widgets based on client support.; Privacy pattern (output splitting) requires developer discipline; no automatic enforcement prevents accidental leakage of private data to model output.; UI is sandboxed but still runs in user's LLM client (not server-side isolation); limited by iframe sandbox restrictions.
  • Implications: MCP apps enable richer agent UX than JSON-only tools: structured displays, interactive controls, real-time co-creation (streaming), user-initiated actions (follow-up messages, tool calls).; Privacy-preserving output splitting unlocks enterprise/regulated use cases (finance, healthcare) by keeping sensitive data in UI and sending only summaries to LLM provider.; Streaming UI updates are powerful for content generation, design tools, data visualization—users see artifact being built in real time, improving transparency and trust.; Ken should understand these primitives to design agent products, evaluate MCP vendor implementations, and decide when MCP apps add value vs. traditional API integrations.; Bidirectional communication means MCP apps can be interactive applications, not just passive displays—this changes the design space for agent tools.

Distribution and discovery: MCP stores, submission process, and dynamic discovery

  • Claims: ChatGPT, Claude, Cursor opened self-serve MCP store submissions; stores were initially closed to design partners but now accepting at scale.; Claude already implements dynamic discovery: when user expresses intent without matching tools, model searches MCP registry and auto-installs best connector.; Submission process: link remote MCP server, providers scan tools/authentication, submit test cases/prompts, partly manual/partly automated review, accept/reject.; Once accepted, app appears in directories (chatgpt.com/apps, Claude connectors, Cursor directory) with one-click install URLs; no more sharing JSON config files.; ManiFact Cloud automates readiness checks (compliance validation) and generates submission artifacts (screenshots, test cases).
  • Evidence: Pietro: 'ChatGPT and Claude are both accepting more and more apps… this is the moment to publish yours.' Claude team/enterprise accounts have self-serve submission form launched ~2 weeks before talk.; Dynamic discovery on Claude: 'When cloud needs to be assigned a task that doesn't have a specific tool to do, it will actually search in the MCP registry for the right connector… more than a billion active users which will manifest an intent directly in the chat… the model will choose what is the best connector.'; Submission requirements: remote MCP server (not local), proper tool annotations and arguments, authentication declaration, test cases/prompts. Acceptance speed varies: ChatGPT 'speeding up a lot,' Claude 'going to take maybe a bit more for now.'; ManiFact Cloud: 'We vet your app to make sure it's ready to be submitted… we check and try to do all the checks those clients will do… also we generate some of the submission artifacts like screenshots and test cases.'; Pietro's traffic example: 'Being on the store brought us a lot of traffic.' Personal buying criterion: 'I'm checking if a product has an MCP server… that for me is the most basic buying decision.'
  • Caveats: Dynamic discovery currently live only on Claude (not yet ChatGPT/Cursor as of talk date), though ChatGPT expected soon.; Submission is partly manual, so no guaranteed acceptance timeline; varies by provider (ChatGPT faster, Claude slower currently).; Claude self-serve submission limited to team/enterprise accounts (not personal accounts as of talk date).; Acceptance criteria differ slightly across ChatGPT/Claude/Cursor stores; need to tailor submission for each.; Remote hosting required (no local-only servers in stores), which may be barrier for some developers.
  • Implications: This is a GTM unlock for software companies: being in MCP stores = organic discovery by billion+ LLM users without traditional distribution spend. Early movers capture intent before competitors.; Dynamic discovery = search distribution layer for software. Products that solve user intent and rank well in MCP registry get installed automatically. This is a new SEO/ASO category.; Ken should prioritize MCP store submissions for any product with API/tool capability, especially in productivity, dev tools, data/analytics categories where Claude/ChatGPT users concentrated.; Submission process requires 1-2 weeks budget; use tooling (ManiFact Cloud or similar) to pre-validate and avoid rejection cycles. Clean tool annotations and robust test cases are critical.; One-click install URLs (vs. JSON config sharing) dramatically lower user friction; this matters for PLG and self-serve adoption.; Being MCP-native is becoming a buying criterion for power users (Pietro's example); products without MCP may lose deals to competitors who have it.

Building MCP apps: MCP-use SDK, client support, and workflow examples

  • Claims: MCP-use SDK (ManiFact open source) abstracts official MCP SDKs; 8M+ downloads, 10k GitHub stars. Provides easier way to build MCP servers and apps.; MCP-use lets developers define tools and return React components as widgets; auto-registers UI resources, compiles to HTML/CSS.; Template available: run 'npx create mcp-use-app' for starter template.; Client support: ChatGPT (web/desktop), Claude (web/desktop), Cursor (agent/chat), VS Code, and others support MCP apps. Support varies (some clients render widgets, some ignore).; Pietro's daily workflow: Granola MCP (meeting notes) + Linear MCP (tickets) + Claude Code (codebase) = pull notes, create tickets, agent opens PRs, closes tickets; 'ideal world' would auto-email customer via MCP.
  • Evidence: MCP-use SDK design: 'You design your MCP server as you always did… define tools… from the tools you can simply return widgets which are automatically registered from this widget file in the resources folder… widget file is just a React component… you can use your existing UI components and it will be compiled into HTML and CSS.'; ManiFact offerings: open-source SDKs, inspector (local testing tool comparable to official MCP inspector), ManiFact Cloud (deploy from GitHub, run evals, publishing checks, team sharing).; Client support list: ChatGPT, Claude (web/desktop), Cursor (agent/normal chat), VS Code, 'countless others.' Can conditionally return widgets only for clients that support MCP apps (MCP-use provides primitives to detect client).; Pietro workflow example: 'I run most of my day to day work on cloud co-work or cloud code because I love the possibility to share the context between my code base and my different connectors… pull meeting notes with some customer feedback and feed it back in linear… create tickets… agent pulls linear ticket through linear MCP and just starts doing it, opens the PR and closes the linear ticket.'; Workflow aspiration: 'In an ideal world it would even send an email back through MCP to the customer saying oh this is fixed. Maybe we're not there yet. But that's definitely true.'
  • Caveats: Client support varies: some render widgets inline/fullscreen/picture-in-picture, some ignore widgets entirely. Need fallback JSON for non-MCP-app clients.; Streaming UI updates and bidirectional communication primitives not uniformly supported across all clients; need testing per client.; MCP-use is one of multiple SDKs; official MCP SDKs also available but require more low-level work.; Workflow example (Granola→Linear→Claude Code) is Pietro's personal setup; not all users have access to all those MCP servers or run same workflow.; Email automation via MCP ('ideal world') not yet available; indicates some gaps in current MCP ecosystem.
  • Implications: MCP-use SDK lowers barrier to building MCP apps; Ken can point developers to npx template for fast prototyping. 8M downloads indicate strong community adoption.; React component pattern (existing UI components → compiled widgets) means teams can reuse frontend code for MCP apps; no need to learn new UI framework.; Pietro's workflow illustrates the 'context-shared across connectors' value prop: MCP enables integrated workflows where one LLM session orchestrates multiple tools (meeting notes → tickets → code → email). This is the killer use case for MCP.; Ken should test MCP apps across multiple clients (ChatGPT, Claude, Cursor) to understand UX differences; can't assume uniform behavior.; Email automation gap ('ideal world… not there yet') suggests MCP ecosystem still maturing; some primitives/connectors missing. Early movers can fill these gaps and capture users.; Being MCP-native is a buying criterion for power users like Pietro; products without MCP may lose deals to those that integrate well with user workflows.

Notable Concepts & Terms

  • MCP apps: MCP servers that return interactive UI components (sandboxed iframes with bidirectional communication) instead of JSON strings when tools are called; official MCP protocol extension as of January 2026.
  • Dynamic discovery: Feature (live on Claude, expected on ChatGPT) where model automatically searches MCP registry when user expresses intent without matching tools, then auto-installs best connector; organic distribution channel for MCP apps.
  • setState primitive: MCP app feature allowing UI widget to update model's knowledge of UI state (e.g., which item is selected); enables model to react to user interactions in UI.
  • sendFollowUpMessage primitive: MCP app feature where UI widget can send messages back to chat (e.g., 'learn more' button sends query to model); Claude prompts user confirmation, ChatGPT auto-sends.
  • Streaming UI updates: Pattern where MCP app receives partial tool inputs as model generates arguments token-by-token and updates UI incrementally in real time (e.g., live diagram drawing, video preview generation).
  • Output splitting (privacy-preserving pattern): MCP app technique where tool returns full sensitive data to UI widget but sends only sanitized summary to model, keeping PII client-side and out of LLM provider logs.
  • MCP-use SDK (ManiFact): Open-source SDK abstracting official MCP SDKs; 8M+ downloads, 10k GitHub stars; lets developers define tools and return React components as widgets, auto-registers UI resources, compiles to HTML/CSS.
  • ManiFact Cloud: Cloud platform for deploying MCP servers from GitHub, running evals, publishing checks (pre-validates store submission readiness), generating submission artifacts (screenshots, test cases), team sharing.
  • MCP stores / directories: ChatGPT (chatgpt.com/apps), Claude (connectors directory), Cursor (directory) platforms where users discover and one-click install MCP apps; self-serve submission now open at scale.
  • requestDisplayMode: MCP app feature controlling how widget is displayed: inline (normal, next to tool call), fullscreen (entire chat is widget with input overlay), or picture-in-picture; useful for video editing, graphical interfaces.

Operator Notes / Why Ken Should Care

  • Dynamic discovery (live on Claude, coming to ChatGPT) = new organic distribution channel for software. Billion+ LLM users express intent → model searches MCP registry → auto-installs best connector. Early movers capture this before competitors. Ken should prioritize MCP store submissions for any product with API/tool capability.
  • MCP apps unlock privacy-preserving agent workflows: show sensitive data in UI iframe but send only sanitized summaries to LLM, keeping PII client-side. This solves major adoption blocker for enterprises/regulated industries (finance, healthcare). Pitch this to privacy-sensitive prospects.
  • Streaming UI updates enable real-time co-creation UX (live diagrams, video previews, code visualizations). Explore this for content generation, design tools, data visualization products. Also useful for agent observability—users see what agent is thinking/building as it works.
  • Submission process requires 1-2 weeks; use tooling (ManiFact Cloud or similar) to pre-validate before submitting to avoid rejection cycles. Clean tool annotations and robust test cases are most common rejection reasons. Remote hosting is non-negotiable (no local-only servers in stores).
  • Pietro's workflow (Granola MCP for meeting notes → Linear MCP for tickets → Claude Code for PRs) illustrates the killer use case: context-shared across connectors in one LLM session. MCP-native products integrate into these workflows; products without MCP may lose deals to those that do.
  • Being MCP-native is becoming a buying criterion for power users (Pietro checks for MCP server as 'most basic buying decision'). Products that ship MCP apps signal they're agent-ready and workflow-compatible.
  • One-click install URLs (vs. sharing JSON config files) dramatically lower user friction for PLG and self-serve adoption. This matters for viral growth and reducing onboarding drop-off.
  • Client support varies (Claude prompts user for UI-triggered messages, ChatGPT auto-sends; streaming fidelity differs). Ken should test MCP apps across ChatGPT, Claude, Cursor to understand UX differences; can't assume uniform behavior.
  • MCP-use SDK (8M+ downloads) lowers barrier to building MCP apps; React component pattern means teams can reuse existing frontend code. Point developers to 'npx create mcp-use-app' for fast prototyping.
  • Email automation via MCP ('ideal world… not there yet' per Pietro) indicates gaps in current ecosystem. Early movers can fill missing primitives/connectors and capture users before ecosystem matures.

Watch Map

  • 00:00: Introduction: Pietro, ManiFact, MCP apps overview (primitives, discovery, future of software)
  • 02:00: ManiFact background: open-source SDKs (8M+ downloads, 10k stars), inspector, cloud platform
  • 03:00: History of MCP: launched 2024, MCP UI proposal mid-2025, ChatGPT app SDK, stores opened late 2025, MCP apps official January 2026
  • 04:30: What MCP apps are: model calls tool → returns widget in sandboxed iframe (not JSON), bidirectional communication
  • 06:00: MCP apps architecture: UI resources declared at init, tool populates arguments, widget rendered by client
  • 07:00: Primitive 1: setState (update model's knowledge of UI state from widget)
  • 08:00: Primitive 2: sendFollowUpMessage (UI button sends message to chat; Claude prompts, ChatGPT auto-sends)
  • 09:30: Primitive 3: streaming UI updates (tool receives partial inputs, UI updates incrementally in real time)
  • 11:00: Primitive 4: callTool from UI (widget button triggers additional tool calls)
  • 12:00: Primitive 5: output splitting (privacy-preserving pattern—show full data in UI, send sanitized summary to model)
  • 13:30: Example: show private user info in widget, tell model 'User is seeing their private information in widget above'
  • 15:00: Additional features: requestDisplayMode (inline/fullscreen/picture-in-picture), open external links, listen to host theme
  • 16:00: Video demos: ManiFact analytics MCP in Cursor, Excalibur MCP streaming diagrams in Claude, ManiFact analytics in ChatGPT
  • 18:00: Client support: ChatGPT, Claude (web/desktop), Cursor (agent/chat), VS Code, others; varies by client
  • 19:00: Distribution and discovery: ChatGPT, Claude, Cursor stores now open for self-serve submissions at scale
  • 20:00: Dynamic discovery (live on Claude, expected on ChatGPT): model searches MCP registry when user expresses intent without matching tools, auto-installs best connector
  • 21:00: Submission process: link remote server, providers scan tools/auth, submit test cases/prompts, partly manual/automated review, accept/reject
  • 22:00: ManiFact Cloud automates readiness checks and generates submission artifacts; once accepted, app appears in directories with one-click install URLs
  • 23:00: Building MCP apps with MCP-use SDK: define tools, return React components as widgets, auto-register UI resources, compile to HTML/CSS
  • 24:30: Pietro's workflow example: Granola MCP (meeting notes) + Linear MCP (tickets) + Claude Code (codebase) = integrated context-shared workflow
  • 26:00: Conclusion: being in MCP stores = huge traffic, MCP server now basic buying decision for Pietro, MCP apps are future of software distribution

Source/Metadata

  • Title: MCP Apps: Primitives, discovery, and the Future of Software - Pietro Zullo, Manufact, Inc
  • Transcript words: 4579
  • Duration seconds: 1734
  • Timestamp note: Timestamps estimated from video duration and content flow; not explicitly provided in transcript, so times are approximate based on 1734-second total length and logical section breaks.

Transcript

4425 words en Processed in 469.7s

Hello y'all, my name is Pietro, I'm the co-founder of ManiFact and today I want to talk to you about MCP apps. Specifically, we're going to talk about the primitives, so how these apps are built, how they work and what they allow you, how to distribute MCP apps, so what is behind the discovery mechanisms of MCP servers and apps in general and why I think you should care about this because this is how software will be used. So I'm sure most people here listening to this talk know what an MCP is. MCP has been around for quite some time since 2024. For a full year, it was a very frequent talk amongst developers and companies that were rushing to build these MCP servers. MCP apps are a less familiar concept. They've been around also for quite some time, more or less since the end of 2025. But when I talk to companies and people in general, I see that many people don't understand what they are and don't understand they can build them. And specifically, they don't know how to distribute them to the MCP apps, but also they don't know the new way to distribute MCP servers as well. So I hope by the end of this talk, you're going to know about this and you're going to be ready to build your first or iterate on your MCP server and app, and you're going to be able to share it with the world in a more efficient way, brings you more customers and more users. A little about me and ManiFact, my company. We build open source SDKs and tools for MCP and MCP Cloud, the manifesto. Open source SDKs by the name of MCP allow developers to build servers and agents in an easier way. So we provide an abstraction over the official SDKs that allows developers to ship faster without worrying about how the spec works beneath. We have eight million plus downloads across our SDKs and we have 10k stars on GitHub. Also open source, the separate product is the inspector. It's an open source inspector. Again, I think comparable to the official inspector from the Model Context Protocol maintainers that allows you to test these MCP servers and apps specifically on your local machine. Once you build, once you test it, we have built the cloud for you to ship. The ManiFact Cloud is a cloud vertical for MCP. We provide all the primitives for you to be able to ship MCP servers from your GitHub repo and test them immediately, share them with your team, run evals, run publishing checks to make sure that your app is ready to be submitted, and many other features that are completely specific to MCP. Of course, we really believe in MCP. So let's look at the history of MCP and how did we get there. So MCP was launched in 2024, and by the end of May 2025, Ido Solomon and Liat-Josef started working on MCP UI, which is a way for MCP servers to return UI components. Then, many people started talking about MCP UI because this is such a great opportunity to ship UI with your MCP servers to agents. So it is interactive experiences where the agent is calling tools, but issuing UIs to the user. This created a lot of movement. Many people enjoyed this proposal and ChatGPT at some point released the app SDK, which is a way to create these interactive MCP apps, basically MCP servers that also return UI elements. Also, at the end of 2025, quite silently, both ChatGPT and Claude released and opened their stores for MCP. These stores allow you to submit your MCP server and have a one-click install experience for your users. For the most time, these stores were closed and it says they were designed and only allowed for design partners, but things have changed and I'm happy to talk about this lately. In January 2026, MCPUI, let's say, converted to MCP apps. MCP apps is now the official extension of the model context protocol that allows to return UI elements within MCP servers. So this timeline is an explanation of how the protocol evolved. And I think two major things happened in this timeline. First, MCP apps. MCP servers are not only returning JSON and that allows much richer experiences. And the second thing, maybe even bigger, is that the stores opened. This was a great, huge move by the model providers, Anthropic, OpenAI, Cursor, basically every LLM client out there to say, oh, MCP is the way and we want to have a way for people to publish vetted and quality MCP servers so that people can use them with a one-click install experience. This is the situation right now with the stores. The apps that are now being submitted to ChatGPT and Claude, apps for ChatGPT and connectors for Claude, are increasingly being accepted. As I was saying, in the beginning, this was a feature that was gated behind design partnership because the ecosystem was very young, but now ChatGPT and Claude are both accepting more and more apps. So this is the moment to publish yours. So let's see what MCP apps actually are and what you can do with them. So an MCP app works in the following way. Much of this is very similar to MCP. The model is the host of the tools. The tools are in an MCP server. But the MCP server in this case doesn't return a JSON string again, but it returns a widget in a sandboxed iframe. So the experience you see is your model is streaming text. At some point it decides to make a tool call. The tool call is not just returning JSON. It returns a UI just underneath. And this UI is a sandbox iframe. So you can, as a company developing these apps, you can put almost whatever you want. But it doesn't end there. Actually, there is a bidirectional communication that happens between the iframe and the host application. So from the iframe, from the MCP app UI elements, you can send messages back to the host. And this is a way to do that. So from the iframe, you can interact in several ways. I'm going to talk more about that later. The way this works is that MCP declares UI resources at the initialization time. When the model calls the tool and it populates the arguments of the tool, the tool can then populate the arguments of the UI resource. And that can be then displayed and rendered by the client. As you see here, this is the kind of experience that you can see in an MCP app. The MCP server returns a UI resource that is populated with the tool arguments. And here you see, so without UI, you would see a wall of text. The UI allows you to organize the information in a more human readable way. So this is the basics of MCP apps. I think that many times they've been talked about. And today I wanted to show a bit more of what you can do because this is not often mentioned. And I think it's very interesting to design new experiences which these new protocols allow. So first of all, again, the UI is displayed in the chat and it exposes a communication channel between the UI element and the host application. So the host application will listen for these messages going through these channels and will react accordingly. So this is the first primitive that I'm going to talk about. The UI allows you to organize the information in a more human readable way. So this is the basics of MCP apps. I think that many times they've been talked about. And today I wanted to show a bit more of what you can do because this is not often mentioned. And I think it's very interesting to design new experiences which these new protocols allow. So first of all, again, the UI is displayed in the chat and it exposes a communication channel between the UI element and the host application. So the host application will listen for these messages going through these channels and will react accordingly. So this is the first primitive that I'm going to talk about. So model context. In the UI, you can show whatever information you want. For instance, in this case, we're showing three articles, but the model doesn't really know. It cannot really introspect in real time what is going on in the UI. But the protocol mandates this state or this set state primitive where you can update the state of the model with respect to the UI components. So from the widget itself, you can call this is an MCP use syntax that makes this easier. The set state primitive and you can update what the model knows about what's being displayed. So here we have a little demo that shows this. Of course, the message prompts the tool and the tool shows the UI. The state of this UI element is that nothing is selected and the model knows about this. But if you modify the UI state, you can communicate this state change to the model itself. So that if, for example, here I send another message, the model will be aware of what happened in the UI element. And you can do this by simply using this primitive set state and update the state that the model knows about. UI message. So this is another very cool feature where from the UI element, the UI widget that your tool returns, you can send messages back to the model. So not only is the interaction I am a user, I have my chat interface, I see the UI and I want to send another message. Maybe there is some contextual message that you want to send. And for instance, here we have the same shoe example. And you might want to learn more about Trailblazer Pro. And you can, of course, link the click of this button "learn more" to the primitive send follow-up message. And this will send a message to the chat itself and the model can start giving you more information about the Trailblazer Pro shoe in this case. Clients have different behavior regarding this, and this is true for many of the MCP features. For instance, Claude will display the message in the chat input and tell the user, the user has the choice to send it or not. While OpenAI is a bit more integrated in this sense, directly sends the message to the model and starts streaming immediately the answer to that message. This is a very cool feature. So again, we have the tool and we have a UI element that's populated from the tool itself, right? If the model streams the input tokens into the tool arguments, you can take those partial inputs and update the UI incrementally. So as you see in this case, we see that the tool inputs are being populated dynamically or gradually and the UI reacts accordingly. We have a very cool demo about this just later in a video where I think one of the coolest demos of MCP apps uses exactly this pattern. So you can, for example, imagine you could have a UI component that renders something like an SVG and there are MCP apps doing that. We also created a Remotion MCP app where we use Remotion to create a video with React and we render the Remotion video inside the widget in real time as it tokens the stream in. Another thing you can do is from the widget itself, you can call other tools. So first of all, you can call the tool, of course, in the tool that was originally called to gather other data. But from the UI, for example, you can have a button that triggers another tool call to gather additional data about what is there in the MCP server. Again, the primitive is very simple. This code on the left here is always from MCP use. This is another very interesting thing that you can do with MCP apps. So sometimes what happens is, for instance, you want your MCP server to return certain information, but you want to not show the full information because maybe it's private information that you don't want to give to the model providers. And therefore, you might want to reduce that information, right? This is a known privacy issue with MCP servers that you want to return and put into your private information. And MCP apps allow you to do that. So when you call a tool, you return a widget which is populated with some arguments, but you can return other outputs as well. As in normal MCP servers, the return of an MCP tool is a list of outputs of different types. You can imagine in this case, there is a structured output which is sent into the widget itself. And there is an additional output that can be sent directly to the model. So something common that you do is you show a very rich UI like in this case. And this is what the UI will show. So this is a card showing the information, private information of this person, but the model will only see the information you want. So there's two types of output. The ones that are shown in the UI, to put it simply, and the ones that are sent to the model. So a common pattern that you see is you show the full information in the UI, and then you instruct the model with a text output of what the user is seeing. For instance, we return this UI card and we can even return nothing to the model. But just say the user is seeing its private information in the widget above. So this is a pattern that allows you to give, allow experiences in fields where maybe sharing data to the LLM is not possible because of privacy issues. In this case, you can show the UI to the user, but the model won't see the data that you display in the UI, unless you choose so. There's another set of functionalities which I think are minor or less counterintuitive or less advanced. Here we show the request display mode, which basically your MCP app widget is displayed in line with the tool call. But it can even be full screen. So the full chat is going to be your MCP widget and the input box is going to be overlaid on top of the widget. And for instance, this is very cool for video editing. You can imagine a widget showing some graphical interface and you can chat to improve what's shown inside the widget and the model can directly stream into the widget you're looking at. It can also be put in picture in picture or in line, which is the normal case. There are other primitives that allow you to open external links from the MCP widget itself. You can listen to the theme of the host so that your MCP app is synchronized in theme with the host your users are using. There are many other things. So I wanted to show you here a few videos of MCP apps because so far I've just been showing some mock-ups that I created for this presentation. And for instance, this is very cool for video editing. You can imagine a widget showing some graphical interface and you can chart it to improve what's shown inside the widget and the model can directly stream into the widget you're looking at. It can also be put in picture in picture or in line, which is the normal case. There is another primitive that allows you to open external links from the MCP widget itself. You can listen to the theme of the host so that you know your MCP app is synchronized in theme with the host your users are using. There are many other things. So I wanted to show you here a few videos of MCP apps because so far I've just been showing some mock-ups that I created for this presentation. But this is, for example, in Cursor, we're using the MCP app. Cursor is one of the clients that supports MCP apps. And as you see here, our MCP app returns the analytics of the remote MCP server app that I was talking to you about just before. And for instance, this is very useful in analytics. For instance, we use Posting MCP a lot. And then the Posting MCP will show you a UI element with your analytics so that you as a human can understand what's going on. But the model itself can read those analytics and go do its job on the code that you're writing. On Claude, so this is the demo I was telling you about. So here we're using the Excalibur MCP server. And here you will see the streaming functionality that I mentioned just before. So you can see here that Claude is first reading some instructions that are returned as tool by the Excalibur MCP server. And at some point, it will call the tool which is showing the canvas. And it will stream tokens into the canvas. And I think Remotion did some of the coolest animations around how those tokens are shown. As you see here, this is a mermaid syntax that is sent into the tool. And the UI updates as the tokens are streamed in. There's some of the coolest demos here. By the way, very useful to draw diagrams as well. And this is again ChatGPT using the Manifact MCP app showing the same analytics that I was showing you about. And as you see here, the rendering is a bit better in ChatGPT. It was better. This is very similar to how users work. Maybe this is a good time to talk about the client support. There's many clients that support MCP apps. Some do more, some do less. And these three, I think, are the main ones that people are using. And of course, all the different versions of Claude and ChatGPT. So both Claude Web, Claude Desktop support MCP app. ChatGPT and Codex support MCP app. And Cursor, both in the agent mode and in the normal side chat, supports MCP app. But there's many more that support MCP apps, such as VS Code and countless others. And I think it's actually interesting to mention here that another thing you can do, you might be developing your MCP server. And you don't know if the host where your users are using the MCP server supports MCP apps or not. What you can do is, since we know who the client is from the metadata that is exchanged via MCP, you can return a UI element only for those hosts that actually accept and can render those widgets. And this is not really a big deal because most non-MCP app clients, so MCP clients that don't support MCP app, will simply not show the widget. But I found developing these servers many times that if you don't show the widget, you need to return a different output. Because some of the information was in the widget, but maybe you want to give it to the model if the widget is not shown. So this is something that also MCP user helps you with, with some primitives that allow you to know if the client your MCP server is connected to actually supports MCP apps or not. Again, a little idea of how you can build these MCP apps with MCP use. We are one of the most popular SDKs to build these MCP apps. And the way we design our SDK is that you design your MCP server as you always did. So you have your MCP server constructor and then you define tools. And from the tools, you can simply return widgets, which are automatically registered from this widget file in the resources folder. So whatever you put as widget file in the resources folder will be registered as a UI resource that you can return from a tool. And the widget file is just a React component. And you can also use your existing UI components and it will be compiled into HTML and CSS. And then returned and linked to the tool. We have a skill and we have a template. So if you want to do it, you can just run MPX create MCP use app and it will give you a template that you can serve. So let's talk about distribution and discovery, which I think is of course a very important topic. Maybe even less known than how MCP apps work. I'm talking to many people and they don't know there's a store for MCP and they don't know how to submit. So I wanted to talk about this as well. So the store is a huge new distribution channel. Again, here I'm bringing the three most popular clients, ChatGPT, Claude and Cursor, which the three of them all support a self-serve submission process. ChatGPT was one of the first supporting this. Claude, since a couple of weeks, they have a self-serve submission form for team and enterprise accounts. And also Cursor allows you to submit their MCP server. The way you submit is different for all three, but basically what happens is that you need to make sure that your MCP app is compliant. MCP apps or servers can be submitted in all these three stores. So it doesn't need to return a UI for your server to be eligible for submission. And the three processes to get your app submitted are different and they have different speeds. So it's going to take maybe a bit more on Claude for now. And the ChatGPT instance is speeding up a lot the acceptance of these apps. And again, the process is you link your remote MCP server. They will scan the tool and they will make sure that all the tools are correctly annotated and have the correct arguments. And once this is done, they're going to scan the authentication as well. So if your server requires authentication, you have to declare it and you need to make sure that it works. There's a few more different steps, which are detailed for all the providers. But it's important to say that once your app is submitted, it's going to be partially manually or partially automatically tested. So you will have to provide some test cases and some test prompts, and then it will be either accepted or rejected. And if accepted, you're going to be able to publish it and make it available on the stores that you can find on chatgpt.com slash apps on the connectors directory on Claude or on the Cursor directory. Again, we did many submissions and we tried to make this process easier. So if your server requires authentication, you have to declare it and you need to make sure that it works. There are a few more different steps, which are details for all the providers. But it's important to say that once your app is submitted, it's going to be partially manually or partially automatically tested. So you will have to provide some test cases and some test prompts, and then it will be either accepted or rejected. And if accepted, you're going to be able to publish it and make it available on the stores that you can find on chagipity.com slash apps on the connectors directory on cloud or on the cursor directory. Again, we did many submissions and we tried to make this process easier. So if you want to submit your app, I think you should go to manufacturer.com where we vet your app to make sure that it's ready to be submitted. So we check and we try to do all the checks that those clients will do in the submission process. And also we generate some of the submission artifacts that you need to submit like screenshots and test cases for you. So we can do that in our cloud directly if connected to your MCP server. Something very cool about this is that once your app is in the store, not only can people find it by searching on the store, not only you can send a URL to your customers and they're going to be able to install your application in one click. So you don't have to share that ugly JSON file anymore with your MCP configuration. But it's very important that dynamic discovery of MCP server is happening. Today, cloud is the only client that actually does this. But for all apps in the stores, when cloud needs to be assigned a task that doesn't have a specific tool to do, it will actually search in the MCP registry for the right connector to do the task. So imagine what this means for your particular product. There are many active users on the applications or more than a billion active users, which will manifest an intent directly in the chat. And through the intelligence of the model, the model will choose what is the best connector. And if you're there and you do your work to be the connector that is selected, this is going to be a huge wave of intent individuals that want to need your product and will find it dynamically and organically on those platforms. So this is very important. Cloud does this today. And the judge is expected to do this pretty soon. So that was my descriptive part of the talk. I just want to say, I think it should be clear by now how important it is to be on the stores. It can bring my experience being on the store brought us a lot of traffic. And personally, as a user of MCP, today I'm checking if a product has an MCP server. And that for me is the most basic buying decision. I run most of my day to day work on cloud co-work or cloud code because I love the possibility to share the context between my code base and my different connectors. And this to me is so important. For instance, one workflow that I often run is I have my Granola MCP where I have my meeting notes. I have a linear where I track my tickets. Of course, I'm in my code base if I'm using this from cloud code. And I can pull the meeting notes with some customer feedback and feed it back in linear. Maybe I create tickets for the rest of the team. And then I have the agent that pulls the linear ticket through the linear MCP and just starts doing it, opens the PR and closes the linear ticket. In an ideal world, it would even send an email back through MCP to the customer, saying, oh, this is fixed. Maybe we're not there yet. But that's definitely true.