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

Choosing an MCP App framework is harder than choosing a React starter. An MCP App spans an MCP server, a ui:// resource, a sandboxed iframe, a host bridge, tool calls, model-visible context, security policy, and usually a remote deployment. A framework can cover one of those layers or all of them, so feature lists are easy to misread.

The ecosystem also moved quickly in 2026. The official MCP Apps SDK now has a 2.x package structure for Views, React helpers, hosts, and server registration. ChatGPT documents MCP Apps as its portable UI foundation, and Claude custom connectors can render interactive apps from remote MCP servers. Your choice should hold up across that shared standard and the product-specific behavior around it.

TL;DR: Define the layer you need, score candidates on standards support, development workflow, testing, security, deployment, and escape hatches, then run the same proof app in each one. Give extra weight to evidence you can reproduce locally and in CI. If you need a full project plus a host-aware test stack, sunpeak covers both. If you need a small bridge integration and want to own the surrounding tooling, the official MCP Apps SDK may be enough.

First, Decide Which Layer You Need

The word “framework” covers several different products in MCP Apps. Separate them before you compare them.

Layer	What it owns	What it may leave to you
MCP server library	Tool registration, schemas, transport, requests, and results	UI build, iframe bridge, host preview, tests, deployment
MCP Apps SDK	ui:// resources, the View lifecycle, postMessage transport, host context, and UI helpers	Product structure, fixtures, CI, remote deployment
UI library	Components, hooks, styling, and state in the iframe	MCP server, resource metadata, host behavior, tests
Full app framework	Project layout, server, UI, local host, simulations, tests, and production commands	Provider-specific infrastructure and business logic
Testing framework	Host replica, protocol fixtures, iframe automation, visual checks, and live tests	Your app and server implementation

A server SDK and a full app framework can both be good choices, but they solve different amounts of the problem. Write down the layers your team wants to own before you review APIs.

For a single read-only chart, direct SDK use may be simple enough. For a product with forms, authorization, app-only tools, cross-host support, and regular releases, the local host and testing layers usually save more time than the initial scaffold.

What Changed by September 2026

Three updates should change an older framework comparison.

The official SDK has a clearer package boundary

The current MCP Apps docs split the SDK by role:

• @modelcontextprotocol/ext-apps for a View that talks to its host
• @modelcontextprotocol/ext-apps/react for React bindings
• @modelcontextprotocol/ext-apps/app-bridge for hosts that embed Views
• @modelcontextprotocol/ext-apps/server for tool and resource registration helpers

The current docs pair those packages with the MCP 2.x server and client packages. They also state that the Apps wire protocol remains compatible across ext-apps 1.x and 2.x, so package migration and host compatibility are related but separate questions.

This gives you a useful baseline. A framework should say which package role it wraps, which protocol revision it targets, and where you can access the underlying types and messages.

Standard MCP Apps metadata is now the portable starting point

The portable tool-to-UI link is _meta.ui.resourceUri. The resource uses the MCP Apps media type, text/html;profile=mcp-app, and the host renders it in a sandboxed iframe. The View initializes through the ui/* bridge, receives tool input and results, and can request allowed host actions.

OpenAI’s current UI guide tells new ChatGPT integrations to start with those MCP Apps fields and bridge methods. ChatGPT compatibility aliases and window.openai extensions still exist, but they add host-specific capabilities after the shared path works.

A framework that hides these contracts completely makes migrations harder. Good abstraction removes repetition while leaving the resource URI, tool result, capabilities, and security metadata easy to inspect.

Capability differences matter more than host labels

MCP Apps supports capability negotiation because hosts do not implement every optional request. A View may be able to call a server tool, update model context, open a link, request display mode, read a resource, ask for sampling, or download a file. Each action depends on host support and sometimes user approval.

Choose a framework that exposes capabilities directly and helps you build fallbacks. Branching on a product name is weaker because product behavior changes and two clients from the same vendor can expose different capabilities.

Read the capability detection guide if your app needs more than tool input and result rendering.

Use a Weighted MCP App Framework Scorecard

Score each category from 0 to 5, multiply it by the weight, and divide by 5. A candidate that scores 4 in a 20-point category earns 16 points. Set a minimum score for any requirement that can block your launch, even if the total looks good.

Category	Weight	Evidence to request
MCP Apps standards support	20	Modern resource metadata, official media type, bridge lifecycle, capability negotiation, text fallback
Local development workflow	15	One command to start, real tool calls, saved states, host context controls, useful errors
Automated testing	20	Unit, protocol, iframe end-to-end, visual, cross-host, and live-host paths
Security and authorization	15	CSP fields, sandbox permissions, OAuth boundaries, app-only tool controls, private metadata handling
Deployment and operations	15	Streamable HTTP, resource bundling, health checks, logs, runtime support, versioned resources
Portability and escape hatches	10	Standard types, raw bridge access, host extensions behind capability checks, no forced backend rewrite
Maintenance quality	5	Current docs, migration notes, reproducible examples, release cadence, clear version support

The weights total 100, but your product may need different priorities. An internal read-only dashboard can reduce deployment weight. A public app that handles account data should raise security and authorization weight. A design canvas may put more weight on iframe performance, display modes, and state recovery.

Avoid awarding points for a checkbox alone. “Supports ChatGPT” could mean a static card rendered once. “Has tests” could mean unit tests for utility functions. The evidence column turns each claim into something you can run.

Run the Same Proof App in Every Candidate

A small proof app reveals more than a day of reading. Keep the business logic trivial so you measure the framework.

Build a “review orders” app with one read tool, one View, and one app-only action. Ask each framework to pass these eight checks:

1. Register list_orders with _meta.ui.resourceUri and a versioned ui://orders/v1.html resource.
2. Return concise text for the model plus typed structuredContent for the UI.
3. Render loading, success, empty, error, and cancelled states without changing production code.
4. Add an app-only approve_order tool that the View can call but the model does not see.
5. Detect one optional host capability and render a usable fallback when it is absent.
6. Declare the exact connect and resource domains needed by the iframe.
7. Run an automated browser test that enters the iframe, approves an order, and checks the updated result.
8. Deploy the server over Streamable HTTP and repeat one test against the deployed endpoint.

Record setup time, lines of app-specific code, debugging time, and any undocumented steps. Also record what happens when you intentionally break the resource URI, result schema, CSP domain, and tool name. Error quality matters because most development time happens after the happy path works.

Evaluate Standards Support at the Contract Boundaries

A standards-first framework should make these boundaries obvious.

Tool definition to UI resource

The tool advertises a ui:// resource through _meta.ui.resourceUri. The host reads that resource and expects text/html;profile=mcp-app. Look for first-class helpers that produce standard metadata rather than a framework-only manifest that must be translated later.

Also check resource versioning. Hosts can cache templates, so a breaking UI bundle change should get a new URI. A framework should let you version the resource without renaming the tool or changing the business payload.

Tool result to View

The text content should remain useful to the model and to clients that do not render UI. structuredContent should carry the typed data the View renders. Private UI-only data belongs in _meta when the host contract supports it.

Ask how the framework validates outputSchema and structuredContent. TypeScript types alone do not validate a network result at runtime.

View to host

The View uses JSON-RPC over postMessage, normally through an SDK or framework wrapper. You should be able to inspect initialization, host capabilities, tool input, tool results, context updates, server-tool calls, and teardown.

You may never call the bridge by hand, which is fine. You still need access to the underlying failure when a request is unsupported, denied, timed out, or malformed.

Host support to fallback behavior

MCP Apps is an extension to core MCP. A tool should still provide a useful text or structured result when the client cannot render the View. Test that path deliberately. Portable behavior includes graceful degradation, not only rendering in several host screenshots.

Check the Local Development Loop

The best local loop answers a specific question quickly: what will this app do for this tool call in this host state?

Look for controls over:

• Tool input, partial input, result data, errors, and cancellation
• Light and dark themes
• Inline, fullscreen, and picture-in-picture modes when supported
• Locale, timezone, platform, viewport, and safe areas
• Host capabilities and denied permissions
• Slow tools, repeated tool calls, and remounts
• CSP failures, resource-load failures, and bridge logs

A browser preview that renders only the React component covers layout. An MCP App inspector should also connect the server, tool metadata, resource response, iframe sandbox, bridge messages, and host context.

For an existing server, check whether the framework can connect to an HTTP endpoint or start a stdio command without moving handlers into its own directory structure. That escape hatch matters for Python, Go, Rust, and mixed-language teams.

Demand a Testing Story Beyond Unit Tests

MCP Apps fail at boundaries, so test each boundary at the cheapest useful layer.

Test layer	What it proves	Typical speed
Unit	Rendering and state logic for known hook values	Milliseconds
Contract	Tool schemas, annotations, resources, media types, and result shapes	Milliseconds to seconds
Inspector end-to-end	Server, resource, iframe, bridge, and user interaction together	Seconds
Visual	Theme, viewport, display mode, empty state, and overflow regressions	Seconds
Live host	Current connection, approval, auth, and production host behavior	Slow and less deterministic
Eval	Whether models choose the right tool and arguments for representative prompts	Variable and model-dependent

A framework should help you keep the broad suite local and deterministic. Use a narrow live suite because it depends on accounts, production UI, network conditions, and model behavior. The complete MCP App testing guide explains how to divide coverage across those layers.

Ask whether one saved fixture can drive the inspector, browser test, and visual snapshot. Shared fixtures reduce drift between the state a developer saw and the state CI checked.

Treat Security as Framework Behavior

MCP Apps run inside a host-controlled sandbox, but your server still owns authorization and your resource still declares what it needs.

Verify that the framework makes these tasks direct:

• Declare exact connectDomains, resourceDomains, and any required frameDomains
• Request camera, microphone, geolocation, or clipboard access only when the app needs it
• Keep authorization on every server tool, including app-only tools
• Separate model-visible content from View-only metadata
• Validate tool arguments again on the server
• Keep durable business state on the server instead of iframe storage
• Restrict write actions and make retries idempotent

Run negative tests. Remove an allowed domain, deny a permission, call an app-only tool as an unauthorized user, and replay a write request. The result should be a controlled failure with enough detail to diagnose it. See the iframe sandbox, CSP, CORS, and origins guide for the browser boundaries behind these checks.

Verify the Production Path Before You Commit

ChatGPT Apps and Claude custom connectors connect to remote MCP servers, so local stdio support does not prove production readiness. Ask the framework to show the whole path:

1. Build the UI into an MCP App resource.
2. Start a Streamable HTTP endpoint over HTTPS.
3. Serve stable tools and versioned resources.
4. Authenticate the user and authorize every call.
5. Emit logs that correlate initialization, tool calls, resource reads, and errors.
6. Roll forward or back without leaving tools pointed at missing UI bundles.

Check runtime assumptions too. A framework built around Node file access may need work on an edge runtime. A framework that supports a generic MCP endpoint may fit an existing backend with less change.

Deployment support does not have to mean one hosting vendor. It should mean a documented artifact, transport, configuration model, health check, and rollback plan.

Red Flags in an MCP App Framework

Pause when a candidate:

• Uses only legacy host metadata and has no plan for _meta.ui.resourceUri
• Treats capability support as a product-name check
• Requires a live chat session for routine UI development
• Cannot render error, cancellation, empty, or permission-denied states on demand
• Provides component snapshots but no iframe or bridge tests
• Hides CSP, sandbox permissions, and server authorization behind broad defaults
• Forces an existing MCP server into a new backend stack just to test it
• Has no path from a local server to a remote Streamable HTTP deployment
• Prevents access to raw MCP types or bridge errors
• Claims cross-host support without a repeatable cross-host test matrix

One red flag may be acceptable for a prototype. Several usually mean the team will build the missing framework around the framework.

When the Official SDK Is Enough

The official MCP Apps SDK is a strong base when your team wants a small dependency surface and is comfortable owning project conventions. It now provides View APIs, React hooks, server helpers, and a host bridge package, with starter templates for several UI libraries.

Direct SDK use fits when:

• You have one or two simple Views.
• Your MCP server, auth, deployment, and observability already exist.
• Your team can build the fixture and browser-test layer.
• You need low-level control over bridge messages or host behavior.
• You are building an MCP Apps host rather than only an app.

A full framework makes more sense when several teams need the same local workflow, when every release needs cross-host coverage, or when you want one supported path from scaffold through tests and deployment.

Where sunpeak Fits

sunpeak is an open-source, full-stack MCP App framework and a server-agnostic MCP testing framework. As of September 24, 2026, the current npm release is 0.20.85.

For a new app:

npx sunpeak new orders-app
cd orders-app
pnpm dev

That starts a local MCP server and the sunpeak Inspector, which can render saved tool states in ChatGPT-style and Claude-style runtimes.

For an existing MCP server in any language:

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

This lets you add inspection and automated coverage without moving the server into a sunpeak project. The testing stack includes unit, Playwright end-to-end, visual regression, live-host, and model eval paths. Core hooks such as useToolData, useAppState, useHostContext, useTheme, and useDisplayMode target the portable app contract, while host-specific APIs remain separate.

sunpeak is a fit when the scorecard gives high weight to local host inspection and repeatable tests. Direct use of the official SDK remains a reasonable choice when you prefer to assemble those layers yourself.

A Practical Decision Rule

Choose the smallest option that passes your proof app and your launch constraints.

Use the official SDK directly if the app is small and your team already owns the server, deployment, and browser-test stack. Add a testing framework if the server exists but host behavior is hard to reproduce. Choose a full MCP App framework when you want shared structure, a local host, fixtures, tests, and production commands across several apps.

Before you commit, keep the top two candidates for one extra day. Have a developer who did not build the proof app add an error state, change the output schema, and diagnose a blocked resource. The framework that makes those changes obvious will usually cost less over the next year than the one that won the first ten-minute demo.

Start with sunpeak’s quickstart if you want a complete MCP App project. If you already have a server, start with the testing framework or connect it directly to the Inspector.