Claude connectors: how they work and how to build one for your MCP server

What Claude connectors are

A connector puts your product inside Claude. A person connects it once, signs in with their own account, and from then on Claude can read from your product and act in it during any conversation where the connector is switched on.

Claude connectors are remote MCP servers that Claude talks to on a person’s behalf. MCP, the Model Context Protocol, is the open standard underneath: your server lists tools, Claude reads the list, and Claude calls a tool when a request needs it. The same connector works in claude.ai, the desktop app, the mobile apps, Cowork and Claude Code.

On 10 November 2026 connectors gained a second half. An interactive connector can now open your product’s own interface beside the conversation or full screen, and Claude can work in it while the person watches. This guide covers how a connector works end to end, what the 10 November release changed, how interactive connectors are built on MCP Apps, and how to build, test and list one for your own MCP server.

Directory and custom connectors run on the same infrastructure. The difference is discovery and trust: a directory listing is found inside Claude and carries a Community or Verified label, and a custom connector is found by whoever has the URL.

How a Claude connector works

Every connector, interactive or not, goes through the same 5 steps. Knowing which side controls each one tells you what you can design and what you can only accept.

The approval step is worth a second look, because your server decides how often people see it. Each tool carries annotations: a title, and a hint that says whether it only reads (readOnlyHint: true) or changes data (destructiveHint: true). Claude uses those hints to set default permissions. A person can then set each tool, or each group of tools, to Always allow, Needs approval or Blocked, and on Team and Enterprise plans an Owner can block a tool for everyone.

Authentication follows the MCP authorisation specification, with a few Claude-specific details:

• 3 ways in. OAuth 2.0, where each person signs in with their own account; a static credential that an Owner enters once and Claude sends as a header; or no authentication at all.
• Client registration. Claude can register itself through Dynamic Client Registration. If your authorisation server does not support it, Anthropic documents other ways to give Claude a client identity.
• Callback URL. Allow https://claude.ai/api/mcp/auth_callback for the hosted apps, plus a loopback redirect for Claude Code.
• Spec versions. Claude follows the 2025-03-26, 2025-06-18 and 2025-11-25 authorisation specifications, and refreshes access tokens when they expire.
• Lazy sign-in. Tools that work without an account can run straight away, with sign-in deferred until Claude reaches a tool that needs it.

Use the Streamable HTTP transport. Claude still accepts the older HTTP with server-sent events transport, but it is being retired.

Where connectors run, and the limits that apply

A person connects once in claude.ai, and the connector follows them across Claude’s apps. Each app supports a slightly different set:

Your tool results have to fit inside 2 limits, and they differ between the hosted apps and Claude Code:

Claude implements a subset of MCP. Resource subscriptions, sampling, and advanced or draft capabilities are not supported yet, so a server that depends on them will not work as a connector. Check Anthropic’s connector docs before building on anything newer than tools, prompts and resources.

What interactive connectors added on 10 November 2026

Interactive connectors first shipped on 26 January 2026, built on MCP Apps. Back then a tool such as Asana or Figma could render a small live view inside the conversation. The 10 November release turns that view into a full workspace. Where a connector supports it:

• The tool opens beside the chat or full screen. For tools like Confluence and Notion the person gets the full editor, signed in to their own account, not a preview.
• Claude works in the open tool. Ask it to change a page, a row or a file that is on screen, and the change appears as Claude makes it. The person approves Claude’s actions the same way they approve any connector action.
• Tools open without a prompt. A connected tool can be opened directly, then Claude can be asked for help from the same screen.
• Tools can be pinned. A pinned tool sits beside the person’s artifacts and opens in 1 click from the sidebar or the + menu.

Anthropic named Asana, Canva, Carta, Dropbox, monday.com, Smartsheet, Vercel and Webflow as launch partners, with Adobe, Atlassian, Box, HubSpot and Notion as worked examples, and Figma, Harvey and Shopify building their own. It is rolling out on the web and in the desktop app on all plans, as part of the experience that brings chat and Cowork together. On Team and Enterprise plans, the new features appear once the organisation allows the connector’s tools.

For developers, the important line is that Claude now supports more of the MCP Apps extension, including app tools and embedded sites. Both are in public preview. That is what lets a product’s full interface run inside Claude rather than a summary card of it.

How interactive connectors work: MCP Apps

MCP Apps is an open extension to MCP, identified as io.modelcontextprotocol/ui. It lets an MCP server ship its own interface to any AI app that supports the extension. Claude is one host; VS Code with GitHub Copilot, Microsoft 365 Copilot, Goose and Postman are others. An app built once can run in each of them.

It adds 1 idea to MCP: a tool can point at a page.

• The page is a resource. Your server registers an HTML document as a resource whose URI starts with ui:// and whose type is text/html;profile=mcp-app.
• The tool links to it. The tool’s _meta.ui.resourceUri names that resource. Claude can fetch the page before the tool is even called.
• The page runs in a sandbox. Claude renders it in a sandboxed iframe on its own origin, with a strict content security policy. The page cannot read Claude’s cookies, its storage or the rest of the conversation.
• The page talks over postMessage. The view and Claude exchange JSON-RPC messages: ui/initialize to start, the tool’s input and result pushed into the view, and tools/call requests from the view back to your server, which Claude forwards.
• The text still matters. A tool result carries both content, the text the model and text-only hosts read, and structuredContent, the data the view draws. Send both.

What the page may load is declared up front. _meta.ui.csp lists the origins it may fetch from (connectDomains), load scripts, images and fonts from (resourceDomains) and frame (frameDomains). Leave it out and the host blocks every outside origin.

A view also has a size and a place. In Claude it can sit in 1 of 3 places, and the place it reports is not always the one you would guess. Switch between them:

3 rules govern movement between the places:

• Declare the modes. The view lists them in availableDisplayModes when it starts. The SDK defines inline, fullscreen and pip; any other value, such as sidebar, stops the view from starting.
• Ask for the side panel on the server. Set preferredDisplayMode: "fullscreen" on the resource and Claude tries once to move the view to the side panel after the tool returns.
• Ask for full screen from a click. requestDisplayMode works only straight after a click or key press in the view. A request on load or from a timer is refused.

The side panel is available to a limited set of organisations for now, and not in every conversation. A view that needs it should still work inline.

4 capabilities that let Claude work inside your tool

A view that only displays a result is a chart. The 10 November release is about 4 capabilities that make it a place where the person and Claude both work.

App tools: Claude changes what is on screen

A view can register its own tools with app.registerTool. Claude sees them alongside your server’s tools and can call them to change what the view shows: add an item, select rows, set a value. In the contact view, an app tool such as set_match_by lets the person say “match the other 6 by name and company” and watch the 6 skipped contacts update.

App tools need a remote connector, and in Claude they work in conversations with the unified chat and Cowork experience. A conversation can hold 2 views of the same app, and each call reaches only 1, so write each app tool to change only its own view.

Messages: the view talks to Claude

app.sendMessage sends a message from the view into the conversation. A button labelled “Plan the rest” can ask Claude for a plan without the person typing it. Use it for actions the person started; a view that messages Claude on its own reads as noise.

Embedded sites: your real product, inside the view

A view can load your own website in a nested iframe: your editor, your dashboard. Declare the site’s origin in frameDomains, and allow Claude’s sandbox in your site’s frame-ancestors header. For a directory connector, embedded sites load only under a Verified listing that allows the origin; for a custom connector, Claude lists the origins and asks the person to allow them. When an origin is blocked, the iframe stays empty with no message, so show a fallback.

Entry points: open the app without asking Claude

Mark a tool as a global entry point and Claude can list your app on its Artifacts page, where people open it directly and pin it to the sidebar. The view then starts with no request and no conversation, so every input must be optional and the empty state must be useful. Entry points need a remote connector that is Verified or custom, and a limited set of organisations has them so far.

How to build a Claude connector for your MCP server

Take the CRM used across this site. Its MCP server has 3 tools, find_contacts, update_contacts and log_activity, and a sales team’s agent calls them to update contacts from a trade-show list. Here is the path from that server to an interactive connector.

Host it remotely and pick the auth

• Serve the MCP endpoint over Streamable HTTP at a stable URL on your own domain. Reviewers check that the server’s domain matches your service.
• Choose OAuth if each person should act as themselves. Add the Claude callback URL, and support Dynamic Client Registration or register Claude another way.
• Decide which tools can run before sign-in. Read-only, public tools are good candidates for lazy authentication.

Shape the tools the way review expects

• Split reads from writes. A catch-all api_request tool with a method argument is rejected. Ideally split writes further into create, update and delete.
• Annotate every tool. A title, plus readOnlyHint: true or destructiveHint: true. These set the default permission each person sees.
• Name and describe narrowly. Names of 64 characters or fewer. Descriptions that say what the tool does and when to call it, and never tell Claude how to behave or which other tools to use.
• Return useful errors. “Internal Server Error” fails review. Say what to change: “Updated 3 of 9 contacts. 6 had no email match; retry with match_by set to name_and_company.”
• Keep results small. Return what the task needs, not the whole account, and well under the 150,000-character limit.

Add the view

With the MCP Apps SDK (@modelcontextprotocol/ext-apps), registerAppTool and registerAppResource write each host’s metadata for you. The tool points at a ui:// resource and returns both text and structured content:

registerAppTool(server, 'update_contacts', {
  title: 'Update contacts',
  description: 'Update contacts from imported rows. Returns each contact updated and any row skipped because it had no match.',
  inputSchema: {
    rows: z.array(z.object({ email: z.string(), name: z.string(), company: z.string() })),
    matchBy: z.enum(['email', 'name_and_company']).default('email')
  },
  annotations: { readOnlyHint: false, destructiveHint: false },
  _meta: { ui: { resourceUri: 'ui://crm/contacts' } }
}, async ({ rows, matchBy }) => {
  const result = await updateContacts(rows, matchBy);
  return {
    content: [{ type: 'text', text: `Updated ${result.updated.length} of ${rows.length}. ${result.skipped.length} had no match by ${matchBy}.` }],
    structuredContent: result
  };
});

registerAppResource(server, 'Contacts view', 'ui://crm/contacts', {}, async () => ({
  contents: [{
    uri: 'ui://crm/contacts',
    mimeType: RESOURCE_MIME_TYPE,
    text: CONTACTS_HTML,
    _meta: { ui: {
      csp: { resourceDomains: ['https://cdn.crm.example'] },
      preferredDisplayMode: 'fullscreen'
    } }
  }]
}));

In the page, create an App, set ontoolresult to draw the 9 contacts, register any app tools, then call app.connect(). Set handlers before connecting so the first result is not missed.

Set the sandbox domain

Claude serves each app from its own origin: the first 32 hex characters of the SHA-256 of your server URL, followed by .claudemcpcontent.com. If your view calls your API or needs an OAuth callback, set _meta.ui.domain to that value and allow it in your CORS rules. A wrong value shows up as ui.domain mismatch.

Test against the real Claude

• Exercise every tool in the MCP Inspector first, including the OAuth flow.
• Add the server to Claude as a custom connector by URL. Expose a local server through a tunnel first.
• Test app tools, entry points and embedded sites with your own remote server. The example servers run locally, and local views do not get those features.

Submit it to the directory

Anyone on a paid Claude plan can submit through the developer portal; on Team and Enterprise an Owner submits. Bring test credentials for a fully populated account, public documentation by your publish date, and an allowed list of link destinations if your view opens external links. A new listing is labelled Community after an automated policy scan. Anthropic may escalate a listing it judges highly useful to a Verified review, in which reviewers test each tool by hand. Embedded sites and entry points need the Verified label.

Some products are not accepted at all: connectors that move money or crypto, and connectors that generate images, video or audio with AI models. Diagrams, charts and UI mock-ups are fine.

What the directory shows you after launch

Once a connector is listed, the developer portal gives it an Overview and a Usage tab. The numbers are computed daily and can lag by up to 24 hours.

Those are the right numbers for running a server. They count Claude’s traffic only, and they count calls. An update that takes 9 contacts and skips 6 of them is a success on every row of that table. The person who asked for 9 contacts and got 3 shows up nowhere, unless the next call says so.

That gap is what Abracadabra is for. It reads the calls your server receives as tasks: which run of calls was one attempt, which step it stopped at, and what it cost. The MCP observability guide shows the method on the same contact update.

Limitations to plan around

• Most of the new surface is in preview. App tools and embedded sites are in public preview, and the side panel and entry points reach a limited set of organisations. Build so the view still works inline.
• Local servers get less. App tools, entry points and embedded sites need a remote connector.
• The Community label gets less. Embedded sites and entry points that work while you test as a custom connector disappear for people who install a Community listing.
• Claude supports part of MCP. No resource subscriptions, no sampling, no draft capabilities. Events, the proposal for servers to notify agents, is a draft and not in Claude yet.
• The server never sees the conversation. The directory policy also forbids collecting conversation data beyond what a tool needs, and querying Claude’s memory or chat history.

Read the tasks behind the calls

An interactive connector adds a second stream to read: what people do in the view, and which app tools Claude calls there. Together with the server’s calls, it says whether the contacts got updated.

Abracadabra joins both into 1 record per task, so a 200 that skipped 6 contacts shows as a task that stopped on update. It starts free; see pricing.

Claude connectors FAQ

What are Claude connectors?

Claude connectors link Claude to an outside app or service so it can find information there and take actions for the person. Each connector is an MCP server, usually remote, that the person connects once with their own account.

What is an interactive connector in Claude?

An interactive connector is a connector whose MCP server also ships an interface, built with the MCP Apps extension. Since 10 November 2026 it can open beside the conversation or full screen, and Claude can make changes in it while the person watches.

How do I build a Claude connector for my MCP server?

Host the server remotely over Streamable HTTP, add OAuth with Claude’s callback URL, annotate and split your tools, and test it in Claude as a custom connector. For an interface, register a ui:// resource with the MCP Apps SDK and link it from the tool’s _meta.ui.resourceUri.

What is the difference between a directory connector and a custom connector?

Both run on the same infrastructure. A directory connector is reviewed by Anthropic, listed inside Claude and labelled Community or Verified. A custom connector is added by its URL with no review, by a person or an Owner.

Do MCP Apps only work in Claude?

No. MCP Apps is an open extension to MCP, and VS Code with GitHub Copilot, Microsoft 365 Copilot, Goose and Postman also host it. One codebase can serve each host; Claude adds its own ui.domain format and its own limits.

Related guides

• MCP observability: how agents use your MCP server: What your server can see of each agent, and the signals that say a task stopped.
• Claude Managed Agents: what they are and how to run one: The agent, environment, session and events model, including MCP servers as tools.
• AI agent observability: how to monitor agents in production: How traces, evaluations and conversation analytics fit together.
• What is an eval? AI evals explained for product managers: Turn the tasks that stopped into test cases for the next release.

Sources: Anthropic’s announcement of 10 November 2026 and connector developer docs, and the MCP Apps overview. Read on 11 November 2026.