sunpeak is MCP-App-First (June 2026)

MCP Apps are now the shared UI layer for AI host integrations. The official MCP Apps docs define the pattern: an MCP tool declares a ui:// resource, the host renders that resource in a sandboxed iframe, and the app talks to the host over JSON-RPC through postMessage.

That is the right default target for a framework. ChatGPT Apps, Claude Connectors, VS Code extensions, and other host surfaces can add useful differences, but the base app contract should be the open standard.

TL;DR: sunpeak is an MCP App framework built around the MCP Apps standard first. Core APIs cover the portable bridge, resource metadata, tool data, app state, themes, display modes, and host context. ChatGPT and Claude-specific capabilities stay in explicit extension paths. Build against the standard, use host features only when they help, and test the full matrix locally with the sunpeak testing framework.

Why MCP-App-First Still Matters

When developers search for a ChatGPT App framework, they often mean one of two things:

• “I need my app to run inside ChatGPT.”
• “I need an interactive MCP App that can also run inside ChatGPT.”

Those are close, but they are not the same. The second path is usually better because the same resource and tool contract can run in more than one host.

OpenAI’s MCP Apps compatibility guide says ChatGPT supports the MCP Apps open standard for embedded app UIs and recommends using the MCP Apps bridge by default, then reaching for window.openai when a ChatGPT-only feature is needed. The official MCP docs describe the same cross-host model: tools point at UI resources, hosts fetch the resources, render them in sandboxed iframes, and proxy app-host communication.

sunpeak follows that split. The framework should not make your first resource depend on one host’s global object, preview mode, app store workflow, or account plan. The default should be a portable MCP App. The host-specific code should be obvious when it appears.

The Portable Core

In sunpeak, core APIs come from the top-level sunpeak import. They map to concepts that exist in the MCP Apps runtime: tool data, app state, host context, theme, display mode, auto-resize behavior, and resource metadata.

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

export const resource: ResourceConfig = {
  description: 'Show analytics dashboard',
  _meta: {
    ui: {
      csp: {
        resourceDomains: ['https://cdn.example.com'],
      },
    },
  },
};

export function DashboardResource() {
  const { output } = useToolData<{ accounts: Array<{ id: string; name: string }> }>();
  const context = useHostContext();
  const displayMode = useDisplayMode();
  const [selectedAccount, setSelectedAccount] = useAppState<string | null>('selectedAccount', null);

  return (
    <main data-display-mode={displayMode} data-locale={context.locale}>
      {output.accounts.map((account) => (
        <button key={account.id} onClick={() => setSelectedAccount(account.id)}>
          {account.name}
        </button>
      ))}
      <p>Selected account: {selectedAccount ?? 'none'}</p>
    </main>
  );
}

Nothing in that component assumes a particular host. It can render in ChatGPT, Claude, or any host that implements the app bridge. It also gives the model useful state because useAppState lets the app expose interaction state back to the host instead of hiding everything inside local React state.

The server side follows the same idea. A sunpeak tool links to a resource, returns structured data, and lets the host decide how to render it:

import { z } from 'zod';
import type { AppToolConfig } from 'sunpeak/mcp';

export const tool: AppToolConfig = {
  resource: 'dashboard',
  title: 'Show account dashboard',
  description: 'Render account metrics in an interactive dashboard',
  annotations: { readOnlyHint: true },
};

export const schema = {
  accountId: z.string().describe('Account to inspect'),
};

export default async function ({ accountId }: { accountId: string }) {
  return {
    structuredContent: {
      accountId,
      accounts: [{ id: accountId, name: 'Northwind' }],
    },
  };
}

For a deeper architecture walkthrough, read How to Build an MCP App and MCP Concepts Explained.

Host Features Belong Behind Feature Checks

MCP-App-first does not mean pretending every host is identical. ChatGPT may expose file APIs, host-owned modals, or commerce flows through window.openai. Claude Connector workflows may differ around custom connector setup, directory submission, or data access policy. Some hosts support more display modes than others. Some mobile surfaces restrict iframe behavior differently than desktop.

The key is to treat those as optional capabilities, not as the foundation of your app.

import { useHostInfo } from 'sunpeak';

export function ExportControls() {
  const { hostCapabilities } = useHostInfo();
  const canOpenExternalLinks = Boolean(hostCapabilities?.openExternalLinks);

  if (!canOpenExternalLinks) {
    return <CopyReportUrlButton />;
  }

  return <OpenReportButton />;
}

That pattern ages better than a host-name check. A host can add support. A workspace policy can remove support. A mobile app can differ from a desktop app. Feature detection keeps the UI honest, and it gives you a concrete test matrix. For the full pattern, see MCP App capability detection.

Where MCP Apps Run Now

The current host picture is broader than it was when this post first ran in April.

The official MCP Apps overview lists support across Claude, Claude Desktop, VS Code GitHub Copilot, Microsoft 365 Copilot, Goose, Postman, MCPJam, and Archestra.AI, and it points developers to the client support matrix for extension support. ChatGPT supports MCP Apps compatibility through the OpenAI Apps SDK, with standard ui/* JSON-RPC messages over postMessage, standard MCP tool calls through tools/call, and optional ChatGPT-specific extensions when needed.

That means a framework has to optimize for three things:

• The shared MCP Apps contract: ui:// resources, tool metadata, sandboxed iframes, JSON-RPC over postMessage, and server tool calls.
• Host-specific capability layers: ChatGPT file APIs, host-owned modals, display mode behavior, Claude Connector workflows, and future host extensions.
• Testable fallbacks: the app must still give the user a clear path when a host lacks an optional capability.

This is why sunpeak is not just a ChatGPT App framework or a Claude Connector framework. It is an MCP App framework with host-specific support where the standard leaves room for host differences.

Testing Is Where MCP-App-First Pays Off

Portability is easy to claim and hard to prove. You prove it by testing the same resource across host runtimes, themes, display modes, tool results, user states, and viewport sizes.

sunpeak’s Inspector is the local host runtime for that loop. In a new sunpeak project, pnpm dev starts the inspector and local MCP server:

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

If you already have an MCP server, you can inspect it without adopting the full framework:

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

The testing framework uses the same host replica in Playwright, so you can write tests against real iframe behavior instead of plain component mocks:

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

test('dashboard renders in Claude dark mode', async ({ inspector }) => {
  const result = await inspector.renderTool(
    'show-account-dashboard',
    { accountId: 'acct_123' },
    { host: 'claude', theme: 'dark', displayMode: 'inline' },
  );

  await expect(result.app().getByRole('button', { name: 'Northwind' })).toBeVisible();
});

The useful part is not just the happy path. You can pin a simulation fixture where a tool returns an error, a display mode is unavailable, a host lacks server tool calls, or a viewport forces mobile layout. Those states are tedious to reproduce manually in live hosts, but they are normal test cases locally.

The Architecture Rule

Here is the practical rule I use when deciding whether code belongs in the portable core or a host extension:

• If the behavior comes from the MCP Apps standard, use the top-level sunpeak APIs.
• If the behavior depends on one host, isolate it in a host adapter or small feature component.
• If the behavior may or may not exist in the current runtime, feature-detect it and ship a fallback.

That rule keeps the resource understandable. It also keeps migration paths open. A team can start with a ChatGPT App, add Claude Connector support later, and keep most app code unchanged because the core rendering, data, state, and tests already speak MCP Apps.

For more on the framework choice, read How to Choose an MCP App Framework. For a build walkthrough, read MCP App Tutorial.

Get Started

sunpeak is open-source and works locally and in CI with no paid AI host account required for the local loop. Scaffold a project, start the inspector, and build against the MCP Apps standard first.

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

See the quickstart guide, the MCP App framework page, or the MCP testing framework page if you already have a server and want coverage before adding UI.