MCP Apps Explained: Server-Rendered UIs Inside AI Agents

The MCP 2026-07-28 Release Candidate introduces MCP Apps — an extension that lets MCP servers render interactive UI components directly inside AI agent interfaces like Claude Desktop, Cursor, and Windsurf. It's the first time MCP tools can return something other than text, structured data, or an image.

What MCP Apps is

Current MCP tools return content: text, JSON, images, or embedded resources. The client decides how to display it. The server has no say in the presentation — it just returns data and trusts the agent to surface it usefully.

MCP Apps changes this. A tool can now return a UI component — a form, a table, a confirmation dialog, a data visualization — that the agent renders inline in its interface. The UI is defined server-side using a declarative component format; the client renders it using its own design system. The server controls the structure and logic; the client controls the look.

This is closer to how Slack blocks or Notion integrations work than how REST APIs work. The server sends a structured "view" and the client renders it natively.

Why this matters for tool UX

Consider a tool that returns a table of 50 database rows. Without MCP Apps, the agent surfaces this as a wall of text or JSON that the user has to mentally parse. With MCP Apps, the server returns a table component — sortable columns, pagination, highlighted rows — and the agent renders it as an actual table the user can interact with.

Or a confirmation flow: a tool that books a meeting currently has to return text like "I found these 3 times, please confirm which one" and wait for the user to reply in natural language. With MCP Apps, the server returns three option cards with "Confirm" buttons. The user clicks; the tool proceeds. No ambiguity, no round-trip through language.

This matters most for tools that involve user confirmation, complex data display, or multi-step workflows. Text is fine for answers; it's a poor medium for decisions and structured output.

How MCP Apps works

A tool that supports MCP Apps returns a ui field in its response alongside the standard content:

{
  "jsonrpc": "2.0",
  "id": 1,
  "result": {
    "content": [
      { "type": "text", "text": "Found 3 available slots for tomorrow." }
    ],
    "ui": {
      "type": "card-group",
      "cards": [
        {
          "title": "9:00 AM – 9:30 AM",
          "subtitle": "30 min · Google Meet",
          "actions": [
            {
              "label": "Confirm",
              "action": "tools/call",
              "tool": "book_slot",
              "params": { "slotId": "slot_9am" }
            }
          ]
        },
        {
          "title": "2:00 PM – 2:30 PM",
          "subtitle": "30 min · Google Meet",
          "actions": [
            {
              "label": "Confirm",
              "action": "tools/call",
              "tool": "book_slot",
              "params": { "slotId": "slot_2pm" }
            }
          ]
        }
      ]
    }
  }
}

Clients that support MCP Apps render the ui field as an interactive component. Clients that don't support it fall back to the content field — plain text. Backward compatibility is built in.

When a user interacts with a UI element (clicks a button, submits a form), the client makes another MCP tool call with the parameters specified in the action. The tool handles the action and can return another UI component, creating a multi-step flow inside the agent interface.

Component types in the RC

The 2026-07-28 RC defines a base set of component types. Clients are not required to implement all of them — they advertise which types they support in the server/discover response.

card-group — a row or grid of cards with titles, subtitles, metadata, and action buttons. Good for choice presentation.

table — a data table with columns, rows, and optional sorting. Good for structured data output.

form — a structured input form with labeled fields, validation, and a submit action. Good for collecting parameters before a tool call.

confirm — a simple confirmation dialog: a message, a primary action, and an optional cancel. Good for irreversible operations.

progress — a progress indicator for use with the Tasks extension. Shows completion percentage and a status message while a background task runs.

MCP Apps vs. Artifacts

Claude Desktop and Claude.ai already have Artifacts — server-rendered HTML, React components, or SVG that renders in a side panel. MCP Apps is different in two important ways.

First, MCP Apps components are defined in a declarative component format, not arbitrary HTML or JavaScript. The client controls the rendering — the server can't inject scripts or custom styles. This is a security boundary: an MCP server can't execute arbitrary code in the agent's interface.

Second, MCP Apps components are interactive in a structured way. Button clicks trigger specific MCP tool calls with defined parameters — not arbitrary JavaScript handlers. The client mediates all interactions; the server only sees new tool call requests.

Artifacts are richer and more flexible but carry more security surface. MCP Apps are constrained but safe — any MCP server can use them without the client needing to trust the server's code.

Client support

As of the July 28 RC, Claude Desktop has shipped MCP Apps support for card-group, confirm, and form. Cursor and Windsurf have it in preview behind a feature flag. VS Code Copilot has it on their roadmap. Check the client's server/discover capabilities response for the ui capability and which component types it supports before returning MCP Apps responses.

What this means for documentation tools

For tools that serve documentation and knowledge — like AgentReady — MCP Apps opens up new presentation patterns. An ask_site response could return a table of search results with titles, snippets, and "Read more" buttons. A list_sites response could render a browsable card grid of indexed sites rather than a text list. A submit_site response could show a progress bar while the site indexes.

None of this changes what the tools do — the underlying data and logic stay the same. MCP Apps just gives that data better presentation without requiring the client to write custom rendering code for each tool.