Claude Connectors vs Claude Apps: What Developers Need to Know (July 2026)

TL;DR: Claude Connectors give Claude tools and data through remote MCP servers. Claude Apps are interactive connectors that also render MCP App UI inside the chat. Start with the connector contract, add UI only when the user needs to inspect or act on structured data, and test the same tool/resource path locally with sunpeak before you connect it to Claude.

The terms “Claude Connector” and “Claude App” still get mixed together because they sit on the same architecture. Both are built on MCP (Model Context Protocol). Both can appear in Claude’s Connectors Directory. Both extend what Claude can do.

The difference is the user experience. A connector gives Claude a capability. An app gives the user an interface. This post explains the current relationship, the smallest useful implementation, and the tests to run before you ship either one.

Claude Connectors: Data In

Claude Connectors are remote MCP servers that give Claude access to external data and services. When a user enables a connector, Claude can call that connector’s tools to search files, read emails, query a CRM, pull product analytics, update a ticket, or call an internal API.

The connector handles the server work: authentication, authorization, validation, API calls, data shaping, and error handling. Claude decides when to call the tool, receives the result, and uses the returned data in the conversation. In a standard connector, the user sees Claude’s answer, not your custom UI.

The Connectors Directory has grown from an early set of first-party integrations into 375+ connectors across work apps, files, analytics, design, developer tools, sales, finance, and consumer services. Standard examples include Google Drive, Gmail, Google Calendar, Notion, Slack, Stripe, Jira, GitHub, Salesforce, DocuSign, and WordPress. Users can also add custom connectors by pointing Claude at a remote MCP server URL, usually ending in /mcp.

From a developer’s perspective, a standard connector is an MCP server with tools. Claude calls your tool, gets structured data back, and uses that data as context. For the full lifecycle, see How Claude Connectors Work.

Claude Apps: UI Out

Claude Apps are interactive connectors. When Claude calls a tool, the result can include data for the model and a linked app resource for the user. Claude renders that resource inside the conversation, usually as a sandboxed iframe, so users can click, filter, scroll, select rows, submit forms, review diffs, approve actions, or inspect data without leaving the chat.

Figma, Canva, Asana, Slack, Box, Adobe Creative Cloud, and other directory entries show the shape of this pattern: the connector still exposes tools, but selected tool results open visual UI. In the Connectors Directory, these integrations show up as interactive connectors.

Technically, a Claude App is an MCP App. It is an MCP server that exposes both tools and resources. The current MCP Apps contract is built around a tool result, a renderable resource, and host bridge data such as structuredContent, _meta, display mode, host context, and app state.

That distinction matters because the model and the UI do not need the same payload. Put concise facts Claude may reason about in structuredContent. Put UI-only details, when the host supports them, in _meta: pagination cursors, row IDs, signed asset URLs, view hints, analytics flags, or extra data that should not enter the model transcript. For the deeper contract, see MCP App tool results and MCP App outputSchema.

The Relationship

Here is the simplest way to think about it:

• All Claude Connectors are MCP servers.
• Claude Apps are Claude Connectors that also include MCP App resources (UI).
• Not all connectors are apps, but all apps are connectors.

If your connector only returns data for Claude to reason over, it is a standard connector. If your connector renders an interactive UI for the user, it is a Claude App. Most teams should build the standard connector path first because it forces the tool schema, auth model, result shape, and error handling to be clear before UI complexity enters the system.

You can also build both in one integration: the tool returns data Claude can use in text, and the same result opens a UI for the user. That is the sweet spot for dashboards, design files, pull request reviews, calendars, invoices, project boards, data notebooks, and any workflow where Claude should talk about the result while the user inspects or edits it.

Building a Standard Connector

A standard connector starts with a remote MCP server and one well-scoped tool. Here is a minimal example:

import { McpServer } from '@modelcontextprotocol/sdk/server/mcp.js';
import { z } from 'zod';

const server = new McpServer({ name: 'my-connector', version: '1.0.0' });

server.tool(
  'get-metrics',
  { timeframe: z.enum(['day', 'week', 'month']) },
  async ({ timeframe }) => {
    const data = await fetchMetrics(timeframe);
    return { content: [{ type: 'text', text: JSON.stringify(data) }] };
  }
);

Claude calls get-metrics, gets JSON back, and uses the returned data in its answer. No UI involved.

A production connector needs more than the sample above:

• An HTTPS endpoint Claude can reach, commonly with a /mcp path.
• Clear tool names, descriptions, input schemas, and output schemas.
• OAuth if the connector accesses private user data in production.
• Tool annotations for read-only versus write actions.
• Error messages that tell Claude what failed and what can be retried.
• Tests for auth, empty states, rate limits, malformed inputs, and permission boundaries.

For the full walkthrough of building, deploying, and submitting a connector, see the Claude Connectors Tutorial. You can also review tool design patterns, data access patterns, and OAuth setup.

Building a Claude App (Interactive Connector)

A Claude App adds an MCP App resource on top of the connector. The resource is the UI, and the tool result is the data contract between the server, Claude, and the iframe.

import { useToolData, SafeArea } from 'sunpeak';
import type { ResourceConfig } from 'sunpeak';

export const resource: ResourceConfig = {
  description: 'Display metrics as an interactive dashboard',
};

interface MetricsData {
  title: string;
  metrics: { label: string; value: string; change: string }[];
}

export function MetricsDashboard() {
  const { output } = useToolData<unknown, MetricsData>(undefined, undefined);
  if (!output) return null;

  return (
    <SafeArea className="p-4 font-sans">
      <h1 className="text-xl font-bold mb-4">{output.title}</h1>
      <div className="grid grid-cols-3 gap-4">
        {output.metrics.map((m) => (
          <div key={m.label} className="p-3 bg-gray-50 rounded-lg">
            <div className="text-sm text-gray-500">{m.label}</div>
            <div className="text-2xl font-bold">{m.value}</div>
            <div className="text-sm text-green-600">{m.change}</div>
          </div>
        ))}
      </div>
    </SafeArea>
  );
}

useToolData receives the tool output. SafeArea handles safe rendering across hosts.

The fastest way to get started is with sunpeak:

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

This scaffolds a full MCP App project and starts a local inspector. You can build and test the tool, resource, display modes, themes, safe areas, host context, and simulation states before connecting a real Claude account. The same core app can run in Claude and ChatGPT if you stay on the shared MCP Apps contract and put host-specific features behind feature detection.

If you want to go deeper, the MCP App tutorial covers the full project structure, and How to Build a Claude App covers architecture decisions specific to the Claude host.

The Tool Result Contract

The most common mistake is treating a Claude App as “a React app in Claude.” That misses the hard part. The hard part is the tool result contract:

• content gives the model a normal MCP response.
• structuredContent gives the model and app a typed object, usually validated by outputSchema.
• _meta can carry UI-only helper data when the host supports it.
• The resource metadata tells the host which UI to render.
• App state lets the UI keep local interaction state without asking the model to restate everything.

Design that contract before you polish the UI. If the result is too vague for Claude, the app will feel random in conversation. If the result is too large for the model, you will leak UI implementation detail into the transcript. If the result is only usable by the UI, Claude cannot explain what the user is seeing.

Which Should You Build?

Build a standard connector if:

• You want Claude to have access to a data source (database, API, SaaS tool)
• The data is best consumed as facts Claude can reason over
• You don’t need a custom UI beyond Claude’s text responses

Build a Claude App (interactive connector) if:

• You want users to interact with a visual interface inside the chat
• Your data is best shown as a dashboard, form, gallery, map, or other structured UI
• Users need to review, edit, approve, filter, or compare information
• The UI state matters after Claude’s initial tool call

Build both if your integration benefits from data access and visual presentation. Many of the first-party connectors do exactly this.

Portability

Standard connectors are MCP servers and can work anywhere MCP is supported: Claude, ChatGPT, VS Code, Goose, Claude Code, and other MCP clients. You may still need host-specific connection setup, auth settings, and review steps.

Claude Apps are MCP Apps, so the portable layer is the shared tool/resource contract. ChatGPT Apps use the same basic pattern: a tool returns structuredContent and _meta, and a component renders that result inside the host. Host behavior still differs around display modes, iframe policies, auth setup, file handling, and approval flows, so portable does not mean “never test in the target host.”

With sunpeak, the core sunpeak APIs such as useToolData, useAppState, SafeArea, useDisplayMode, and useHostContext stay host-agnostic. Host-specific behavior lives behind subpath imports such as sunpeak/chatgpt or sunpeak/claude. See Building One MCP App for ChatGPT and Claude for the full cross-host story.

Testing

Whether you build a standard connector or an interactive app, you will want automated tests. sunpeak’s testing framework supports the full range:

• Unit tests for individual tools, schemas, auth gates, and resource components. See How to Unit Test MCP Apps and Testing Claude Connectors.
• End-to-end tests that simulate the full host runtime. See E2E Testing MCP Apps.
• Visual regression tests for themes, display modes, safe areas, and responsive layouts. See Visual Regression Testing for MCP Apps.
• Live host tests for the deployed connector path. See Live Testing Claude Connectors and ChatGPT Apps.
• CI/CD pipelines that run the suite on every push. See MCP App CI/CD with GitHub Actions.

The best practical workflow is:

1. Unit test the tool handler and output schema.
2. Render the app resource with pinned simulation data.
3. Run E2E tests against Claude and ChatGPT runtime replicas.
4. Run visual tests across light, dark, inline, fullscreen, and mobile states.
5. Validate the deployed remote MCP server in the real host before directory submission.

The Complete Guide to Testing ChatGPT Apps and MCP Apps covers the full testing strategy from start to finish.

If you are deciding where to start, build a standard connector first. Make the tool useful in a plain Claude response. Then add the Claude App layer where UI gives the user a better way to inspect, compare, approve, or edit the result.