MCP Apps

What is this?#

MCP Apps are MCP servers that expose tools with associated UI resources. When the agent calls one of these tools, CopilotKit automatically fetches the resource and renders the UI component in the chat; no additional frontend code required.

Key benefits:

• Zero frontend code — UI components are served by the MCP server
• Full interactivity — components can use HTML, CSS, and JavaScript
• Secure sandboxing — content runs in isolated iframes
• Thread persistence — MCP Apps are stored in conversation history and restored on reconnect

Wire the runtime to your MCP server(s)#

A single mcpApps.servers entry on the runtime is all it takes. The runtime auto-applies the MCP Apps middleware to every registered agent: each time an agent calls a tool backed by an MCP UI resource, the middleware fetches the resource and emits an activity event that the built-in MCPAppsActivityRenderer renders inline in the chat as a sandboxed iframe.

MCP Apps with Intelligence#

The mcpApps option works the same way on a runtime connected to Intelligence. The two options do different jobs:

• mcpApps configures the agent side. On every run, the runtime attaches the MCP Apps middleware to the agent.
• intelligence replaces the runner. Intelligence stores the threads and runs, so the MCP Apps in a conversation are restored when the thread is loaded.

To move an existing MCP Apps runtime to Intelligence, keep mcpApps as it is. Remove runner, then add intelligence and identifyUser:

import {
  BuiltInAgent,
  CopilotKitIntelligence,
  CopilotRuntime,
  createCopilotRuntimeHandler,
} from "@copilotkit/runtime/v2";

const agent = new BuiltInAgent({
  model: "openai/gpt-5.4",
  prompt: "You are a helpful assistant.",
});

const runtime = new CopilotRuntime({
  agents: { default: agent },
  // Intelligence stores threads and runs. Do not pass `runner` as well.
  intelligence: new CopilotKitIntelligence({
    apiKey: process.env.CPK_INTELLIGENCE_API_KEY!,
  }),
  // Replace this fixed user with the user from your verified session.
  identifyUser: () => ({ id: "demo-user", name: "Demo User" }),
  // Unchanged from the in-memory setup.
  mcpApps: {
    servers: [
      {
        type: "http",
        url: "https://mcp.excalidraw.com/mcp",
        serverId: "excalidraw",
      },
    ],
  },
});

const handler = createCopilotRuntimeHandler({
  runtime,
  basePath: "/api/copilotkit",
});

export const GET = handler;
export const POST = handler;
export const PATCH = handler;
export const DELETE = handler;

Keep the same serverId values when you move to Intelligence. The stored MCP Apps in a thread refer to the server by that ID.

To give a server to one agent only, add agentId to its entry in mcpApps.servers. On an Intelligence runtime, prefer this to attaching MCPAppsMiddleware to the agent yourself: the runtime then checks each request from an MCP App against the servers of that agent.

For the API key, user identity, and route protection, follow the Intelligence quickstart.

No frontend renderer needed#

Unlike custom activity types, the MCP Apps renderer is already registered by CopilotKit out of the box. A plain <CopilotChat /> is enough; no renderActivityMessages prop, no manual useRenderActivityMessage wiring.

Sandbox and widget storage#

Each MCP App runs in a sandboxed iframe with an opaque origin. A widget can't read your page's cookies, storage or DOM. It can't read responses from your APIs either, unless an API allows cross-origin requests (for example with Access-Control-Allow-Origin: *). It can still send requests, though, so protect state-changing endpoints against cross-site request forgery as you would for any other site. The trade-off is that the widget can't use localStorage, sessionStorage, IndexedDB or cookies of its own either.

Requests a widget makes that need CORS, such as <script type="module"> and fetch, are sent with Origin: null. Serve public widget assets with Access-Control-Allow-Origin: *. Classic <script src> tags don't need CORS. To avoid CORS entirely, bundle the widget into a single HTML file, as the ext-apps examples do with vite-plugin-singlefile.

The MCP Apps spec pairs allow-same-origin with a sandbox served from a separate origin. CopilotKit loads the sandbox inline, so it leaves allow-same-origin off rather than give widgets your page's origin.

If you wrote a widget yourself and it needs storage, you can restore allow-same-origin:

<CopilotKit runtimeUrl="/api/copilotkit" mcpApps={{ allowSameOriginFallback: true }}>
  {children}
</CopilotKit>

Transport types#

The middleware supports two transport types:

HTTP#

Use this format to connect to an MCP server that accepts standard HTTP requests:

{
  type: "http",
  url: "http://localhost:3101/mcp",
  serverId: "my-http-server"
}

SSE#

Use this format to connect to an MCP server that streams events over a persistent connection:

{
  type: "sse",
  url: "https://mcp.example.com/sse",
  headers: {
    "Authorization": "Bearer token"
  },
  serverId: "my-sse-server"
}

Example MCP servers#

Try these open-source MCP Apps servers to get started:

• Excalidraw — collaborative whiteboard rendered in-chat
• modelcontextprotocol/ext-apps — canonical reference implementations

Choose your AI backend