How to Choose an MCP App Framework in 2026 (April 2026)

MCP Apps are interactive UIs that run inside AI hosts like ChatGPT and Claude. They’re built on the Model Context Protocol, now governed by the Linux Foundation, and as of April 2026, they run in ChatGPT, Claude, VS Code, and Goose. The MCP ecosystem has grown to over 10,000 public MCP servers and 97 million combined monthly SDK downloads. If you’re building an MCP App, the framework you pick will determine how fast you ship, how reliably you test, and whether your app actually works across hosts.

TL;DR: Evaluate a framework on five things: local inspector, cross-host portability, testing infrastructure, project conventions, and deployment tooling. sunpeak is the open-source MCP App framework that covers all five.

Why You Need an MCP App Framework

MCP Apps aren’t regular web apps. Your UI components render inside a sandboxed iframe controlled by the AI host. They receive data from MCP tool invocations over JSON-RPC 2.0. They adapt to different display modes (inline, picture-in-picture, fullscreen) and themes (light, dark). They need to work on ChatGPT and Claude and VS Code and whatever host ships MCP App support next.

Building all of that from scratch means solving the same problems every time:

• No local preview. Without an inspector, the only way to see your app is to connect it to a live AI host. That means a paid ChatGPT Plus account, an ngrok tunnel, and a slow feedback loop.
• No testing story. You can’t run CI tests against a live ChatGPT session. Without framework-provided test infrastructure, you’re deploying untested UI to production.
• No portability guarantee. If you build directly against one host’s SDK, your app won’t work on other hosts without rewriting.
• No project conventions. Every project starts from zero. No standard file structure, no resource discovery, no build pipeline.

An MCP App framework solves these problems so you can focus on your product.

What to Look For

1. A Local Inspector

This is the most important feature. You need to see your app render locally without connecting to a live host.

sunpeak ships an inspector that replicates the ChatGPT and Claude MCP App runtimes at localhost:3000. It supports all display modes, light and dark themes, device types, and mock tool invocations with hot module replacement. You see exactly what users see in ChatGPT or Claude, without the round trip. You can also point it at any existing MCP server:

pnpm dev
# Inspector at http://localhost:3000
# MCP server at http://localhost:8000

# Or inspect any MCP server
npx sunpeak inspect --server http://localhost:8000

A framework without an inspector is like a web framework without a dev server. It technically works, but the development experience is painful.

2. Cross-Host Portability

Your MCP App framework should target the MCP App standard, not a single host. sunpeak’s core APIs are built around the standard protocol:

import { useToolData, useHostContext, useDisplayMode } from 'sunpeak';
import type { ResourceConfig } from 'sunpeak';

export const resource: ResourceConfig = {
  description: 'Analytics dashboard',
};

export function DashboardResource() {
  const { output } = useToolData();
  const context = useHostContext();
  return <div>{/* Works on ChatGPT, Claude, VS Code, Goose */}</div>;
}

Host-specific features come from subpath imports, so your base app stays portable:

import { useRequestDisplayMode } from 'sunpeak/chatgpt';
import { useConnectorData } from 'sunpeak/claude';

This separation matters. If you hardcode against one host’s API, you’ll rewrite when you need to support another. With 12 major launch partners already building MCP Apps (Figma, Asana, Slack, Salesforce, Canva, and others), cross-host portability is a real requirement, not a theoretical one.

3. Testing Infrastructure

MCP App testing is different from regular web testing. Your UI depends on tool invocation data, display mode state, and host context that don’t exist in a normal browser environment.

A good MCP App framework should cover the full testing pyramid:

• Simulation files for defining deterministic UI states (tool inputs, outputs, display mode)
• Unit testing with Vitest that renders components with mock host context
• End-to-end testing with Playwright that runs against the local inspector
• Visual regression testing with screenshot comparison across hosts, themes, and display modes
• Snapshot testing for component structure and tool output shapes
• Performance testing for tool latency, cold start time, and bundle size
• Multi-model LLM evals testing tool calling across GPT-4o, Claude, and Gemini
• Live host testing against real ChatGPT with Playwright
• CI/CD compatibility so all tests run in headless mode on every push

sunpeak includes all of this. A simulation file looks like this:

{
  "tool": "get_dashboard",
  "userMessage": "Show me last week's analytics",
  "toolInput": { "timeRange": "7d" },
  "toolResult": { "structuredContent": { "visits": 1234, "conversions": 56 } }
}

And your tests run against these states automatically:

pnpm test           # Unit + e2e tests
pnpm test:visual    # Visual regression across hosts and themes
pnpm test:eval      # Multi-model LLM evals
pnpm test:live      # Live tests against real ChatGPT

Without testing support, you’re shipping UI that you’ve only manually checked in one host, in one display mode, with one set of data. That’s a problem when your app needs to work on ChatGPT, Claude, and VS Code simultaneously.

4. UI Components and Hooks

MCP Apps run in sandboxed iframes, so you’re responsible for your own styling. An MCP App framework should ship production-ready components for common patterns so you’re not rebuilding them from scratch on every project.

sunpeak ships production-ready UI components (cards, layouts, forms, data displays) with built-in theming and CSS variable support. It also provides 20+ typed React hooks for common MCP App patterns: useToolData, useHostContext, useDisplayMode, useAppState, useTheme, and more.

5. Project Scaffolding and CLI

A good framework gets you from zero to working app in under a minute:

npx sunpeak new

This creates a project with TypeScript, React, Vite, and the MCP server pre-configured. sunpeak uses convention-over-configuration: resource components go in src/resources/, tool handlers in src/tools/, simulation files in tests/simulations/, and the build system discovers them automatically.

The CLI handles the full lifecycle:

• pnpm dev — start the dev server and inspector with HMR
• pnpm build — create production bundles
• pnpm start — launch the production MCP server
• pnpm test — run all tests against the local inspector

You can also initialize testing for an existing MCP server project:

npx sunpeak test init --server http://localhost:8000

6. Deployment Tooling

MCP Apps need to be served from somewhere. The framework should make deployment straightforward.

sunpeak’s build tooling creates production bundles you deploy with your production MCP server. It supports zero-config deployment with pnpm start, custom Express mounting via createMcpHandler, and serverless platforms like Cloudflare Workers, AWS Lambda, and Fly.io.

Red Flags

Watch out for these when evaluating an MCP App framework:

• No inspector. If you can’t test locally, your development loop is slow and expensive.
• Single-host lock-in. If the framework only targets ChatGPT or only targets Claude, you’ll rewrite when you need the other.
• No testing support. “Test it manually in ChatGPT” is not a testing strategy. You need unit tests, e2e tests, and CI/CD support at minimum.
• Closed source with usage fees. MCP is an open standard governed by the Linux Foundation. The tooling around it should be open too.
• No cross-display-mode support. MCP Apps render in inline, picture-in-picture, and fullscreen modes. If your framework doesn’t let you preview and test all three, you’ll miss layout bugs your users won’t.