Merge pull request modelcontextprotocol#1868 from conorkel/mcp-apps-blog

Mcp apps blog

Author: ochafik

blog/content/posts/2025-11-20-adopting-mcpb.md

@@ -19,7 +19,7 @@ A basic bundle structure looks like:
 bundle.mcpb (ZIP file)
 ├── manifest.json      # Required: Bundle metadata and configuration
 ├── server/            # Server implementation
-│   └── index.js       
+│   └── index.js
 ├── node_modules/      # Bundled dependencies
 └── icon.png           # Optional: Bundle icon
 ```
@@ -38,20 +38,20 @@ Anthropic originally developed this format (previously called DXT) for Claude's
 
 ## What this means for developers
 
-**Servers:** You can now package your local MCP servers for distribution across multiple clients. The `mcpb` CLI helps you create a `manifest.json` and package your server into a `.mcpb` file. Once packaged, users can install your server with a single click in any client that supports MCP Bundles. 
+**Servers:** You can now package your local MCP servers for distribution across multiple clients. The `mcpb` CLI helps you create a `manifest.json` and package your server into a `.mcpb` file. Once packaged, users can install your server with a single click in any client that supports MCP Bundles.
 
 **Clients:** You can add support for MCP Bundles to your application using the open-source toolchain. The repository includes the schemas and key functions used by Claude for macOS and Windows to implement bundle support, which you can adapt for your own client.
 
 ## Getting started
 
-Check out the repo to get started: [modelcontextprotocol/mcpb](https://github.com/modelcontextprotocol/mcpb). We encourage feedback and contributions. 
+Check out the repo to get started: [modelcontextprotocol/mcpb](https://github.com/modelcontextprotocol/mcpb). We encourage feedback and contributions.
 
 ## Acknowledgements
 
 Thanks to the MCP contributors and maintainers involved in making this happen, including:
 
-* David Soria Parra (MCP Lead Maintainer)
-* Adam Jones (MCP Maintainer)
-* Joan Xie (MCPB Maintainer)
-* Felix Rieseberg (MCPB Maintainer)
-* Alex Sklar (MCPB Maintainer)
+- David Soria Parra (MCP Lead Maintainer)
+- Adam Jones (MCP Maintainer)
+- Joan Xie (MCPB Maintainer)
+- Felix Rieseberg (MCPB Maintainer)
+- Alex Sklar (MCPB Maintainer)

blog/content/posts/2025-11-21-mcp-apps.md

@@ -0,0 +1,117 @@
++++
+date = '2025-11-21T22:00:00+00:00'
+publishDate = '2025-11-21T22:00:00+00:00'
+draft = false
+title = 'MCP Apps: Extending servers with interactive user interfaces'
+author = 'Anton Pidkuiko (Maintainer), Olivier Chafik (Maintainer), Ido Salomon (MCP-UI), Liad Yosef (MCP-UI), Nick Cooper (Core Maintainer), Sean Strong (Anthropic), Jerome Swannack (Anthropic), Alexei Christakis (OpenAI), Bryan Ashley (OpenAI)'
+tags = ['apps', 'ui', 'user interfaces']
++++
+
+Today we're proposing an MCP extension to standardize support for interactive user interfaces in the Model Context Protocol. This addresses one of the most requested features from the MCP community and builds on proven work from [MCP-UI](https://github.com/idosal/mcp-ui) and [OpenAI Apps SDK](https://developers.openai.com/apps-sdk/).
+
+MCP Apps is an optional extension that enables servers to deliver interactive user interfaces to hosts. It introduces a standardized pattern for declaring UI resources, linking them to tools, and enabling bidirectional communication between embedded interfaces and the host application.
+
+The SEP was authored by MCP core maintainers at OpenAI and Anthropic, together with the MCP-UI creators and lead maintainers of the MCP UI Community Working Group.
+
+## Standardization for interactive interfaces
+
+Currently, MCP servers are limited to exchanging text and structured data with hosts. While this works well for many use cases, it creates friction when tools need to present visual information or gather complex user input.
+
+Consider a data visualization server that returns chart data as JSON. The host application must interpret that data and render it, a burden that falls on every client implementation. Or imagine a configuration tool that needs to collect multiple related settings from users. Without UI support, these interactions become awkward exchanges of text prompts and responses.
+
+The community has been creative in working around these limitations, but different implementations use different approaches, making it harder for servers to work consistently across hosts. With lack of standardization, there’s a real risk of fragmentation in the ecosystem.
+
+## Building together
+
+The [MCP-UI project](https://github.com/idosal/mcp-ui), created by Ido Salomon and Liad Yosef and maintained by a dedicated community, spearheaded the vision of agentic apps with interactive interfaces. The project developed patterns for delivering rich user interfaces as first-class MCP resources, proving that agentic apps fit naturally within MCP’s architecture. Backed by a large community and providing rich SDKs, it drove adoption at leading companies and projects such as Postman, Shopify, HuggingFace, Goose, and ElevenLabs.
+
+The [OpenAI Apps SDK](https://developers.openai.com/apps-sdk/) further validated the demand for rich UI experiences within conversational AI interfaces. The Apps SDK enables developers to build rich, interactive applications inside ChatGPT using MCP as its backbone. To ensure interoperability and establish consistent security and usage patterns across the ecosystem, we (Anthropic, OpenAI and MCP-UI) are collaborating to create an official MCP extension for interactive interfaces.
+
+## MCP Apps specification
+
+We're proposing a specification for UI resources in MCP, but the implications go further. MCP Apps is starting to look like an agentic app runtime: a foundation for novel interactions between AI models, users, and applications. The proposal is intentionally lean, starting with core patterns that we plan on expanding over time.
+
+### Key design decisions
+
+**Predeclared resources**
+
+UI templates are resources with the `ui://` URI scheme, then referenced in tool metadata.
+
+```ts
+// Server registers UI resource
+{
+  uri: "ui://charts/bar-chart",
+  name: "Bar Chart Viewer",
+  mimeType: "text/html+mcp"
+}
+
+// Tool references it in metadata
+{
+  name: "visualize_data_as_bar_chart",
+  description: "Plots some data as a bar chart",
+  inputSchema: {
+    type: "object",
+    properties: {
+      series: { type: "array", items: .... }
+    }
+  },
+  _meta: {
+    "ui/resourceUri": "ui://charts/bar-chart",
+  }
+}
+```
+
+This approach enables hosts to prefetch and review templates before tool execution, improving both performance and security. It also separates static presentation (the template) from dynamic data (tool results), enabling better caching.
+
+**MCP transport for communication**
+
+Instead of inventing a custom message protocol, UI components communicate with hosts using MCP's existing JSON-RPC base protocol over `postMessage`. This means:
+
+- UI developers can use the standard `@modelcontextprotocol/sdk`
+- All communication is structured and auditable
+- Future MCP features automatically work with the UI extension
+
+**Starting with HTML**
+
+The initial specification supports only `text/html` content, rendered in sandboxed iframes. This provides:
+
+- Universal browser support
+- Well-understood security model
+- Screenshot and preview generation capabilities
+- A clear baseline for future extensions
+
+Other content types such as external URLs, remote DOM and native widgets are explicitly deferred to future iterations.
+
+**Security first**
+
+Hosting interactive content from MCP servers requires careful security consideration. The proposal addresses this through multiple layers:
+
+1. **Iframe sandboxing**: All UI content runs in sandboxed iframes with restricted permissions
+2. **Predeclared templates**: Hosts can review HTML content before rendering
+3. **Auditable messages**: All UI-to-host communication goes through loggable JSON-RPC
+4. **User consent**: Hosts can require explicit approval for UI-initiated tool calls
+
+These mitigations create defense in depth against malicious servers while preserving the flexibility developers need.
+
+**Backward compatibility**
+
+MCP Apps is an optional extension. Existing implementations continue working without changes, and hosts can gradually adopt UI support at their own pace. Servers should provide text-only fallback for all UI-enabled tools and return meaningful content even when UI is unavailable, so they can serve both UI-capable and text-only hosts.
+
+## What's next
+
+The [UI Community Working Group](https://github.com/modelcontextprotocol-community/working-groups/issues/35) has been instrumental in shaping this proposal through extensive feedback and discussion. We have built an [early access sdk](https://github.com/modelcontextprotocol/ext-apps) to demonstrate the patterns & types described in the SEP. The [MCP-UI](https://mcpui.dev/) client and server SDKs support these patterns.
+
+We invite you to:
+
+- Review the full specification in [SEP-1865](https://github.com/modelcontextprotocol/modelcontextprotocol/pull/1865)
+- Share feedback and concerns in the GitHub issue
+- Join the discussion in the `#ui-cwg` channel on [MCP Discord](https://discord.gg/modelcontextprotocol)
+- Test prototype implementations and share your experience
+
+## Acknowledgements
+
+This proposal wouldn't exist without the work of the maintainers at MCP-UI, OpenAI and Anthropic.
+
+Ido Salomon and Liad Yosef, through MCP-UI and moderation of `#ui-cwg`, incubated and championed many of the patterns that MCP Apps now standardizes, and together with contributors demonstrated that UI resources can be a natural part of MCP. Sean Strong, Olivier Chafik, Anton Pidkuiko and Jerome Swannack from Anthropic helped steer the initiative and drive the collaboration. Nick Cooper, Alexei Christakis, and Bryan Ashley from OpenAI have provided valuable direction from their experience building the Apps SDK.
+
+Special thanks to the UI Community Working Group members and everyone who contributed to the discussions that shaped this proposal.