mcp-apps

Bridge your existing Module Federation remotes to AI-native interactive UIs via the MCP Apps standard.

• ✅ Fully compliant with MCP Apps standard
• ✅ Dynamic tool registration from configuration
• ✅ CORS proxy for CDN resources
• ✅ Protocol-relative URL handling
• ✅ CSP configuration support
• ✅ AI-friendly Skills for configuration management

<video src="https://github.com/user-attachments/assets/8c9647ce-0398-41e3-b69d-f9fb420c31b5" controls width="100%"></video>

The MCP Apps standard lets AI hosts (Claude, VS Code, Goose, etc.) render interactive UI components inside conversations. But it raises a practical question: where does the UI come from?

The standard approach requires an MCP Server to provide a self-contained HTML resource — React, component code, and styles all bundled together. This means:

• UI components must be extracted from your existing project and rebuilt with a separate bundling pipeline
• Each MCP tool needs its own build artifact
• Updating a component requires rebuilding and redeploying the MCP Server's static assets
• Shared dependencies like React are duplicated across every tool's bundle

Module Federation solves all of this by flipping the model.

Instead of bundling UI into the MCP Server, the server holds a configuration file (mcp_apps.json) that points to your existing MF remotes. The UI lives where it already belongs — in your frontend deployment pipeline.

| | Standard MCP Apps | This project | |---|---|---| | UI source | Self-contained HTML bundle inside MCP Server | Existing MF remote, loaded dynamically from CDN | | Adding a new tool | Extract component → create new build → redeploy server | Add one entry to mcp_apps.json | | Updating UI | Rebuild bundle → redeploy server | Deploy new version to CDN, bump versio