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

MCP Apps are interactive UIs delivered by MCP servers and rendered inside AI hosts like ChatGPT and Claude. The framework you choose now has to handle more than React components. It has to handle the MCP protocol, the MCP Apps UI bridge, host security rules, remote connector deployment, and tests that run before you ever connect to a live chat host.

That changed the framework checklist. In April, the main question was whether a framework could make an MCP App run. In June 2026, the better question is whether it can keep the same app portable, testable, secure, and easy to ship across ChatGPT Apps, Claude Connectors, and the next MCP host you need to support.

TL;DR: Pick an MCP App framework with a local inspector, standards-first APIs, deterministic test fixtures, host adapters, secure resource metadata, and clear deployment support. sunpeak is built around that workflow: scaffold the app, inspect it locally, test it in CI, then run live host checks when you are ready.

What Changed Since April 2026

The MCP App ecosystem is more concrete now. The official MCP docs describe MCP as an open protocol supported by AI assistants and developer tools, with a path for building interactive MCP Apps. The MCP Apps launch post explains the app model: server-declared UI, sandboxed iframe rendering, JSON-RPC communication, user consent for tool calls, and support across Claude, Goose, VS Code Insiders, and ChatGPT.

OpenAI’s current Apps SDK docs are also explicit about portability. ChatGPT implements the MCP Apps standard for UI integration, and OpenAI-specific extensions live separately when you need ChatGPT-only behavior. That is the right shape for a framework API: portable defaults, host-specific features behind clear imports.

Claude has its own connector model. Anthropic’s support docs say custom connectors using remote MCP are available across Claude, Cowork, and Claude Desktop plans, with Free users limited to one custom connector while the feature is in beta. Claude can also render interactive connectors as inline cards or fullscreen views. For framework selection, this means you need to think about public remote MCP servers, OAuth, organization controls, and interactive UI behavior, not just local stdio servers.

What an MCP App Framework Must Handle

MCP Apps are not normal web apps embedded in a page you control. A host owns the conversation, iframe, permissions, display mode, theme, and tool-calling flow. Your app owns the UI and server behavior inside that contract.

A framework should cover the parts that repeat across every app:

• A project structure for tools, resources, schemas, auth, and simulations
• A local inspector that renders host states without a live ChatGPT or Claude session
• Typed access to tool inputs, tool results, host context, display mode, theme, and app state
• Resource metadata for CSP, domains, widget behavior, and permissions
• Tests for unit logic, tool contracts, e2e flows, visual states, live hosts, and evals
• Deployment support for remote MCP servers that hosts can reach over the internet

If a framework only gives you a component library, it is not enough. The hard work is the contract between the MCP server, the host, the iframe, and the model.

The Framework Checklist

1. Standards-first API design

Start with the MCP Apps standard, not one host’s private API. Your core app should read tool results, update model context, call server tools, and render UI through portable MCP Apps concepts. Host-specific features should be additive.

In sunpeak, shared app code uses core hooks and types:

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

export const resource: ResourceConfig = {
  description: 'Review customer usage trends',
};

export function UsageResource() {
  const { output } = useToolData<unknown, { accounts: Array<{ name: string }> }>();
  const host = useHostContext();
  const displayMode = useDisplayMode();

  return (
    <section data-host={host.name} data-display-mode={displayMode}>
      {output?.accounts.map((account) => <p key={account.name}>{account.name}</p>)}
    </section>
  );
}

Host-specific code should be obvious at the import boundary:

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

That split matters because ChatGPT Apps and Claude Connectors will not expose every feature in the same way. A framework should make the shared path easy and the host-specific path explicit.

2. Local inspection for every important state

You should be able to render the app before you deploy it. A local inspector should let you switch host, theme, display mode, viewport, tool input, tool result, and auth-like states.

sunpeak’s inspector runs locally and can either load a sunpeak project or inspect an existing MCP server:

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

npx sunpeak inspect --server http://localhost:8000/mcp

This is where most framework comparisons should start. If you cannot inspect a broken state locally, you will debug it through tunnels, host caches, manual prompts, and screenshots. That is slow, and it usually misses edge cases.

3. Test fixtures that model real tool flows

MCP App testing is mostly state testing. Your UI depends on tool input, tool output, resource metadata, host context, and sometimes follow-up calls from the UI back to the server.

A useful framework should let you define those states as fixtures:

{
  "tool": "get-usage",
  "userMessage": "Show me accounts with usage spikes this week",
  "toolInput": { "range": "7d" },
  "toolResult": {
    "structuredContent": {
      "accounts": [{ "name": "Acme", "change": 42 }]
    }
  }
}

Then the same fixture should drive unit tests, e2e tests, visual regression tests, and inspector previews. That keeps your test data close to the app states users actually see.

sunpeak includes Playwright fixtures for the inspector, MCP server calls, iframe traversal, and host switching:

import { expect, test } from 'sunpeak/test';

test('usage cards render in Claude fullscreen', async ({ inspector }) => {
  const result = await inspector.renderTool('get-usage', {}, {
    host: 'claude',
    displayMode: 'fullscreen',
    theme: 'dark',
  });

  await expect(result.app().getByText('Acme')).toBeVisible();
});

4. Security and resource metadata

The MCP specification calls out consent, data privacy, tool safety, and access controls because MCP servers can expose powerful actions. MCP Apps add another surface: remote UI rendered inside a host-controlled iframe.

Your framework should make safe metadata normal:

• Declare resource domains instead of allowing arbitrary external loads
• Keep tool annotations close to handlers
• Separate model-visible data from app-only _meta
• Require explicit action tools for writes and purchases
• Make OAuth and per-user permissions part of the server plan

This is especially important for Claude custom connectors because remote MCP servers are reachable from Anthropic’s cloud infrastructure, and connector users may grant access to external services. It also matters for ChatGPT Apps because submission review and app quality depend on predictable behavior, clear permissions, and a UI that matches host expectations.

5. Deployment support for remote MCP

Local stdio MCP servers are useful for development tools, but ChatGPT Apps and Claude custom connectors need reachable remote MCP endpoints. Your framework should answer these questions without extra glue code:

• What is the production MCP endpoint?
• How are resources bundled and served?
• Where does OAuth live?
• How are CSP and CORS configured?
• Can the same app run on Cloudflare Workers, Express, or another server runtime?
• Can CI run the same tests before deployment?

sunpeak’s quickstart creates a project with a local MCP server for development and a production build/start path. For existing servers, sunpeak can add tests without forcing a rewrite:

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

That matters if you already have an MCP server in Python, Go, Rust, or TypeScript and need a testing layer before adding richer UI.

Red Flags When Choosing a Framework

Be careful if a framework:

• Only targets one host and treats portability as future work
• Requires manual testing in a live ChatGPT or Claude conversation for normal development
• Does not model tool results, _meta, display mode, theme, and host context in tests
• Hides host-specific behavior behind generic APIs
• Has no story for remote MCP deployment, OAuth, CSP, or public endpoints
• Treats MCP Apps like plain iframes with no model-context or tool-calling flow

The risk is not just developer friction. The risk is shipping an app that works in one demo state and breaks when the host changes display mode, delays a tool result, blocks a resource domain, or renders the same UI inside a different client.

Where sunpeak Fits

sunpeak is an open-source MCP App framework and MCP testing framework. It is also a ChatGPT App framework and Claude Connector framework because it targets portable MCP Apps first, then adds host-specific support where needed.

Use sunpeak when you want:

• npx sunpeak new to scaffold tools, resources, React UI, simulations, and tests
• A local inspector that replicates ChatGPT and Claude app runtimes
• Typed hooks for tool data, host context, theme, display mode, app state, and server tools
• Simulation fixtures for deterministic app states
• Playwright e2e and visual tests against the inspector
• Live host tests when you need a final production check
• Multi-model evals for tool-calling behavior
• A way to test existing MCP servers without adopting the full app framework

You can still build directly on the MCP SDK and the MCP Apps package. That is the right choice if you want to own every layer yourself. A framework earns its keep when you want the boring parts handled: local preview, repeatable tests, project conventions, host switching, and CI.

Practical Decision Rule

Choose the framework that lets you answer these questions with code, not promises:

1. Can I render every important state locally?
2. Can I run those states in CI?
3. Can I keep shared app code portable across ChatGPT and Claude?
4. Can I isolate host-specific features when I need them?
5. Can I deploy a remote MCP server with clear resource and security metadata?

If the answer is yes, you have a framework. If the answer is no, you have a starter kit.

Start with sunpeak’s quickstart if you want a full MCP App project. Start with sunpeak’s testing framework if you already have an MCP server and want local, automated coverage before adding app UI.