Why You Need a ChatGPT App Framework (July 2026)

ChatGPT Apps have a cleaner shape than they did a few months ago. OpenAI now documents ChatGPT App UI work through the MCP Apps standard: use _meta.ui.resourceUri, talk to the host through the ui/* bridge, call server tools through the MCP tool surface, and reserve window.openai for ChatGPT-specific extensions.

That makes the case for a ChatGPT App framework more practical. The hard part has moved beyond getting an iframe onto the screen. The hard part is keeping the MCP server, UI resource, host bridge, schemas, resource metadata, and tests in sync while the app grows.

TL;DR: A current ChatGPT App framework should be MCP-first. It should help you define tools and resources, validate structuredContent with outputSchema, handle _meta.ui.resourceUri, wrap the ui/* host bridge, test display modes and host context locally, and keep ChatGPT-only window.openai calls behind feature detection. sunpeak does this with a local inspector, project scaffolding, React hooks, UI components, simulation fixtures, Playwright tests, visual regression tests, live host tests, and multi-model evals.

What Changed Since Early ChatGPT Apps

Early ChatGPT App examples often started from the Apps SDK surface and the window.openai global. That worked for getting a demo running in ChatGPT, but it pushed teams toward code that knew too much about one host.

The current guidance is different. OpenAI says ChatGPT supports the MCP Apps open standard, where app UIs run in sandboxed iframes and communicate with the host through ui/* JSON-RPC over postMessage. The same page recommends building with MCP Apps standard keys and bridge methods by default, then adding ChatGPT extensions only when the shared spec does not cover the feature.

That means a framework should help you write this kind of app:

App need	Portable MCP Apps path	ChatGPT-specific path
Link a tool to a UI	_meta.ui.resourceUri	_meta["openai/outputTemplate"] as a compatibility alias
Receive host and tool state	ui/initialize, ui/notifications/tool-input, ui/notifications/tool-result	window.openai compatibility state
Call a server tool from UI	tools/call through the bridge	window.openai.callTool
Send a follow-up message	ui/message	window.openai.sendFollowUpMessage
Update model-visible UI context	ui/update-model-context	window.openai.setWidgetState
Use ChatGPT-only features	Feature-detected extension layer	File handling, checkout, host modals

This is the biggest reason a framework matters in June 2026. It should keep the standard path boring and repeatable, while still letting you use ChatGPT features when they are worth it.

What a ChatGPT App Framework Actually Does

A ChatGPT App has more moving pieces than a normal React app.

At minimum, you need:

• An MCP server that exposes tools and resources.
• Tool descriptors with useful names, descriptions, inputSchema, optional outputSchema, annotations, and _meta.ui.resourceUri.
• A UI resource that the host can fetch and render in a sandboxed iframe.
• Resource metadata for CSP, permissions, border hints, and host behavior.
• A bridge layer that receives tool input, tool results, host context, display mode, theme, safe area, locale, and viewport data.
• Tool results that separate content, structuredContent, and _meta.
• A local test loop that does not require refreshing a live ChatGPT development app after every save.

You can wire all of that by hand. For a small proof of concept, that may be fine.

For a maintained app, the problem is drift. The server thinks the tool returns one shape. The resource reads another shape. The model sees too much data in structuredContent. The app-only pagination tool shows up to the model. The resource loads locally but fails in ChatGPT because the CSP forgot an API domain. A fullscreen layout works, but picture-in-picture cuts off the primary button.

A good framework turns those failure points into defaults, helpers, and tests.

The Framework Checklist I Would Use

If you are choosing a ChatGPT App framework today, I would ask these questions before writing product code.

1. Is it MCP-first?

The framework should treat ChatGPT Apps as MCP Apps, not as ChatGPT-only widgets. That means the standard fields should be first-class:

• _meta.ui.resourceUri for linking a tool to a UI resource.
• _meta.ui.visibility for model-visible, app-visible, or app-only tools.
• ui/* bridge methods for host communication.
• tools/call for server calls from the rendered UI.
• content, structuredContent, and _meta as separate result channels.
• outputSchema when a tool returns structured data.

The framework can still include ChatGPT-specific helpers. It just should not make those helpers the base contract.

In sunpeak, the base APIs are built for portable MCP Apps. ChatGPT and Claude-specific behavior lives behind host-specific imports and feature gates, which keeps the shared app code easier to test.

2. Can you run the app locally like a host would run it?

A normal browser tab is not enough. Your app is going to run inside a host-controlled iframe with display modes, theme variables, safe areas, bridge events, tool lifecycle messages, and resource metadata.

A framework should give you a local inspector that can render realistic states:

• Initial load before a tool result arrives.
• Successful tool results.
• Empty results.
• Server errors.
• User-cancelled or approval-gated flows.
• Inline, fullscreen, and picture-in-picture layouts.
• Light and dark themes.
• Mobile widths and safe area constraints.

sunpeak includes a replicated ChatGPT and Claude inspector for this. For a new project, run:

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

For an existing MCP server, run:

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

That local loop is the fastest way to find UI and data-contract bugs before you connect the app to ChatGPT developer mode.

3. Does it make schemas hard to skip?

The MCP tools specification defines inputSchema, optional outputSchema, and annotations on tool definitions. For UI-backed tools, skipping the output side is a common source of broken apps.

Use this split:

• content is the short model-readable text summary.
• structuredContent is the JSON object the model and app can reason over.
• _meta is for UI-only helper data when the host supports it.
• outputSchema describes the structuredContent contract.

For example, a search tool should not return a vague array and hope the resource knows what to do:

return {
  content: [{ type: 'text', text: `Found ${items.length} tickets.` }],
  structuredContent: {
    tickets: items.map((item) => ({
      id: item.id,
      title: item.title,
      status: item.status,
      updatedAt: item.updatedAt,
    })),
  },
  _meta: {
    nextCursor: page.nextCursor,
  },
};

The app resource can render structuredContent.tickets. The model gets a useful summary and safe structured data. The pagination cursor stays out of the model-visible result.

The framework should make that pattern normal, then help you test it.

4. Can it test the whole MCP boundary?

ChatGPT App bugs often cross boundaries. A unit test for a React component will not catch a stale ui:// resource URI. A tool handler test will not catch a broken fullscreen layout. A manual ChatGPT test will catch too much too late.

A useful framework should support several layers:

Test layer	What it catches
Unit tests	Pure helpers, tool handlers, component branches
Integration tests	MCP server calls, tool schemas, result shape, auth errors
E2E tests	Resource rendering inside a replicated host
Visual regression tests	Theme, display mode, viewport, and styling drift
Conformance tests	tools/list, resources/read, resource metadata, CSP, visibility
Live host tests	Real ChatGPT or Claude connection behavior
Multi-model evals	Whether models call the right tools with useful arguments

sunpeak’s testing framework covers this stack with local and CI-friendly tests. You still should run a smaller live pass in ChatGPT before launch, but live testing should not be where you first learn that structuredContent changed shape.

What Building Without a Framework Looks Like

Going framework-free means you own every layer.

You can absolutely do this:

mkdir chatgpt-app
cd chatgpt-app
pnpm init
pnpm add @modelcontextprotocol/sdk express zod

Then you need to:

• Register an MCP server endpoint.
• Define tools, schemas, annotations, and metadata.
• Bundle a UI resource.
• Return the right MIME type and resource metadata.
• Implement or wrap the host bridge.
• Keep ChatGPT compatibility aliases aligned with the standard MCP Apps fields.
• Handle CSP and permissions.
• Write local fixtures for tool states.
• Build a browser harness or use an inspector.
• Add tests for server contracts, rendered resources, and host modes.
• Configure deployment and live testing.

That is a reasonable path if the goal is learning the protocol. It is less reasonable if the goal is shipping an app with users, auth, state, error handling, and ongoing host changes.

When You Do Not Need a Framework

You probably do not need a ChatGPT App framework when:

• You are building a server-only MCP tool with no rendered UI.
• You are writing a throwaway prototype to learn the protocol.
• You have one internal tool, no app UI, and no need for cross-host testing.
• You already have an internal platform team maintaining MCP server, resource, bridge, test, and deployment infrastructure.

If the app has a real UI, multiple states, user data, authentication, app-only server actions, or launch plans, a framework starts paying for itself quickly.

Where sunpeak Fits

sunpeak is an open-source MCP App framework and MCP testing framework. Because ChatGPT Apps are MCP Apps, sunpeak is also a ChatGPT App framework. Because interactive Claude Connectors follow the same app pattern, sunpeak is also a Claude Connector framework.

The important part is the workflow:

1. Scaffold a project with npx sunpeak new.
2. Build tools and resources with typed contracts.
3. Develop in a local inspector that replicates ChatGPT and Claude runtimes.
4. Pin tool states with simulation fixtures.
5. Run unit, integration, E2E, visual regression, live host, and eval tests.
6. Deploy the MCP server and run a smaller real-host launch pass.

That flow keeps the expensive manual loop small. You still test the real host, because real hosts matter. You just do not use ChatGPT developer mode as your first line of feedback for every UI state.

Get Started

For a new ChatGPT App:

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

For an existing MCP server:

npx sunpeak inspect --server <url-or-command>

Start with the quickstart guide, then read the current OpenAI Apps SDK docs, the MCP Apps compatibility guide, and the MCP Apps overview. Those are the references I would keep open while building any ChatGPT App in June 2026.