Part 3: MCP Servers vs. Connectors vs. Apps

Your team builds a beautiful MCP server for Jira integration. Five hundred lines of TypeScript, OAuth flow, error handling, retry logic, the works. It took a week. Then someone on your team opens Claude.ai, clicks "Add Connector," selects Jira, and has the same integration working in thirty seconds. Same data, same actions, zero code.

You didn't waste that week. You learned something important: MCP isn't one thing anymore. It's three things arranged in a hierarchy, and knowing which flavor to reach for — custom MCP Server, managed Connector, or interactive Claude App — is the difference between building for a week and clicking a button.

This is Part 3 of our series on the Claude extension stack. Part 1 covered the mental model — how Rules, Hooks, Skills, and MCP fit together. Part 2 went deep on the internal layers: CLAUDE.md, Git Hooks, and custom Skills. Now we're crossing the boundary into external systems. Everything that connects Claude to the outside world.

The three flavors of external access

Claude connects to external systems through three mechanisms that form a strict hierarchy: custom MCP Servers at the base, managed Connectors in the middle, and interactive Claude Apps at the top. All Claude Apps are Connectors. All Connectors are MCP Servers. But not all MCP Servers are Connectors, and not all Connectors are Apps.

This hierarchy matters because it tells you exactly what each layer adds:

Custom MCP Servers are the foundation. You write the code, you host it (locally or remotely), you handle authentication. Any MCP-compatible client can connect — Claude, ChatGPT, VS Code, Goose, whatever comes next. Full control, full responsibility.

Connectors are MCP Servers that Anthropic manages for you. They handle OAuth, hosting, permissions, and discovery. You don't write code. You click "Add" in the Connectors Directory, grant permissions, and Claude can access that service. Over 200 integrations are available: Gmail, Slack, Notion, GitHub, Stripe, Figma, and growing.

Claude Apps are Connectors that return interactive UI components. Instead of Claude describing what it found in Figma, a Claude App renders the actual Figma canvas inside the conversation. You can interact with it — click, edit, navigate — without leaving Claude. Launched in January 2026, Apps turn Claude from a text interface into a visual workspace.

The practical implication: always check what's already available before writing code. If a Connector exists, skip the custom server. If a Claude App exists, you get richer interaction for free.

MCP Servers: build your own

Custom MCP Servers are the right choice when you're connecting to proprietary systems, internal APIs, or workflows that no managed integration covers. You write the code, you own the hosting, and you get complete control over what Claude can see and do with your systems.

If you're new to MCP Servers, our build-from-scratch tutorial covers the primitives (tools, resources, prompts) and walks through a working implementation. Our advanced patterns guide covers production concerns like OAuth 2.1, gateways, and multi-tenancy. Here, I'll focus on where custom servers fit in the extension stack decision framework.

Local vs. remote

MCP Servers come in two deployment flavors:

Local servers run on your machine, connected via stdio transport. Claude Code spawns them as child processes. They're perfect for development workflows — accessing local files, running build tools, querying local databases. Configuration lives in .claude/settings.json:

{
  "mcpServers": {
    "my-internal-api": {
      "command": "node",
      "args": ["./mcp-servers/internal-api/index.js"],
      "env": {
        "API_TOKEN": "your-token"
      }
    }
  }
}

Remote servers run on your infrastructure (or a cloud function) and connect via Streamable HTTP. They're for production deployments where multiple users or agents need access to the same integration. Remote servers handle their own auth, scaling, and uptime.

When custom is the right call

Build your own MCP Server when:

• Proprietary internal systems. Your company's order management system, your custom CRM, your internal knowledge base. No managed Connector will ever cover these.
• Custom business logic. You need the tool to enforce specific validation, transform data in domain-specific ways, or orchestrate multi-step workflows before returning results.
• Claude Code development workflows. Local MCP Servers that interact with your specific build system, test framework, or deployment pipeline. These are inherently custom to your team's tooling.
• Fine-grained permission control. You want to expose exactly three operations on your database, not the full CRUD that a generic integration might provide.

The important thing to remember: an MCP Server you build is just an MCP Server. It works with any MCP-compatible client. If you build a Jira MCP Server for Claude Code today, that same server works with ChatGPT, Goose, or whatever AI tool your team adopts next year. That's the core thesis of MCP as an industry standard — your investment compounds across the ecosystem.

Connectors: managed MCP for everyone

Connectors are Anthropic-hosted MCP Servers with managed authentication, user permissions, and a discovery directory. They eliminate the engineering work of building and maintaining integrations for popular SaaS tools. If you need Gmail in Claude, you click a button. You don't spin up a Node.js server, implement OAuth, handle token refresh, and deploy it somewhere.

What makes Connectors more than just "pre-built MCP Servers":

Managed authentication. OAuth flows are handled for you. When you add the Slack Connector, Claude.ai walks you through Slack's OAuth consent screen. Token storage, refresh, revocation — all managed. This alone saves days of engineering per integration.

User permissions. Each user grants access individually. Your teammate adding the GitHub Connector to their Claude doesn't give your whole organization access to their repos. Permissions are scoped to the user who grants them.

Discovery. The Connectors Directory is a searchable catalog of 200+ integrations. You don't have to know that an MCP Server exists for Notion — you browse the directory, find it, and add it. This is a fundamentally better UX than hunting for MCP Server repos on GitHub.

Hosting and reliability. Anthropic runs the infrastructure. You don't worry about uptime, scaling, or version updates. When Stripe changes their API, the Connector gets updated without you doing anything.

The Connectors directory

The directory covers the SaaS tools most teams already use:

Productivity: Google Drive, Google Calendar, Gmail, Notion, Asana, monday.com, Box, DocuSign

Development: GitHub, GitLab, Sentry, Linear, Jira

Communication: Slack, Microsoft Teams

Design: Figma, Canva

Data & Analytics: Stripe, Hex, Snowflake

Content: WordPress, Webflow

And the list keeps growing. As of early 2026, there are over 200 integrations, with new ones shipping regularly. For most common SaaS tools, checking the Connectors Directory should be your first move before even considering a custom MCP Server.

Desktop extensions vs. web Connectors

Claude has two surfaces where Connectors appear:

Desktop Extensions run locally through Claude Desktop. They're MCP Servers that connect via stdio, similar to Claude Code's local server model. Ideal for development tools, local file access, and integrations that need to interact with your machine's environment.

Web Connectors run remotely and are accessible through Claude.ai's web interface. These are the managed, cloud-hosted integrations. They work from any browser, any device, without installing anything locally.

The distinction matters for deciding where an integration lives. If it needs local machine access (your file system, local databases, running processes), it's a Desktop Extension. If it talks to a cloud API (Slack, GitHub, Stripe), it's a Web Connector.

Claude Apps: MCP + interactive UI

Claude Apps are Connectors that return interactive UI components directly inside Claude's conversation. Launched in January 2026, they flip the interaction model from "Claude tells you what it found" to "Claude shows you and lets you act on it."

Think about the difference. Without Apps, you ask Claude to find your latest Figma design. Claude calls the Figma Connector, gets back data, and describes it in text: "The design has three frames: a login page, a dashboard, and a settings panel. The login page uses a blue primary button..." You're reading a description of something visual. It's useful but limited.

With the Figma Claude App, Claude calls the same integration but the response includes an interactive Figma canvas that renders right in the conversation. You see the actual design. You can click on frames, inspect layers, leave comments — all without leaving Claude. Then you say "Make the primary button green" and Claude can act on the same visual context you're both looking at.

Apps available today

The initial launch includes integrations where visual interaction adds the most value:

• Figma — Browse designs, inspect components, leave comments directly in the conversation
• Canva — Create and edit designs with Claude's help, see results immediately
• Asana — View and manage project boards, create tasks, update statuses interactively
• Slack — Read and respond to threads with full message context rendered visually
• Box — Browse files, preview documents, manage folders
• Hex — Run data queries and see interactive charts and notebooks
• monday.com — Manage workflows and boards with visual project views

How Apps work under the hood

No new protocol. Claude Apps use MCP's existing tools/call mechanism — the same one powering every MCP Server — extended with structured UI components in the response. When Claude calls a tool from an App-enabled Connector, the server returns data plus a UI specification that the client renders inline.

The flow: Claude identifies a need ("show me the latest Figma mockup") → calls the Figma App's get_design tool via standard MCP → the server returns frame metadata alongside a renderable canvas component → Claude's interface renders it in the conversation → your clicks on the canvas trigger further tool calls back to the server.

What makes this powerful: each layer of the hierarchy builds on the last without starting over. A well-built MCP Server is one step from becoming a Connector. A Connector is one step from becoming an App. Your investment compounds up the stack.

Why this changes the workflow

Every AI assistant before Apps was fundamentally text-in, text-out. Claude could describe your Jira board. You'd read the description, open Jira, do the thing, come back, and continue the conversation. That's three context switches for one action.

Apps kill the round-trip. Your Asana board renders in the chat. Your Figma design is right there. You act on it without leaving. It sounds incremental, but try it once and you'll feel the difference — you stay in flow because the information and the interaction live in the same place.

For teams building AI-powered workflows at Chanl, this pattern is familiar -- the best agent tools are the ones that keep the human in the loop without forcing them to switch contexts. Claude Apps apply the same principle to the AI assistant itself. It's also why MCP integration is central to how Chanl connects agents to external systems.

The decision matrix: which flavor?

Start from the top of the hierarchy and work down. Use the simplest option that meets your needs -- you can always drop to a lower layer later if you need more control.

Here's the decision tree in practice:

Build effort comparison

The tradeoff is clear: Connectors and Apps trade customization for speed and maintenance. Custom MCP Servers trade convenience for control and portability. Neither is universally better.

There's a portability angle here too. Custom MCP Servers work across any MCP-compatible client -- Claude, ChatGPT, VS Code, Goose. Connectors and Apps are currently Claude-specific. If your team uses multiple AI tools, a custom MCP Server gives you portability. If you're all-in on Claude, Connectors save you the engineering.

MCP security: the elephant in the room

MCP Servers run with the permissions you grant them, and the trust boundary is wider than most developers realize. In January 2026, security researchers found three prompt injection vulnerabilities in Anthropic's own official mcp-server-git — meaning even the reference implementation had security flaws. If Anthropic's team can miss injection vectors, your team can too.

The core security challenges with MCP:

Prompt injection via tool outputs

When an MCP Server returns data, that data becomes part of Claude's context. If the returned data contains instructions ("ignore previous instructions and..."), it can influence Claude's behavior. This isn't theoretical — it's been demonstrated in the wild.

Consider a Git MCP Server that returns commit messages. If someone commits a message containing prompt injection text, that text flows through the MCP tool response into Claude's context. Claude doesn't inherently distinguish "data from a tool" from "instructions from a user."

Over-permissioned tool scopes

MCP Servers often request broad permissions to be useful. A GitHub Connector that can read repos, create issues, and manage pull requests has a wide blast radius. If an attacker can manipulate what Claude asks that tool to do (via prompt injection from another source), the tool will execute with all its granted permissions.

The trust boundary problem

Count the things you're trusting in a typical MCP setup: the server code itself, the external service it connects to, the transport layer, and every other MCP Server in the session (because one server's output can influence what Claude asks another server to do). That's four trust boundaries, and unlike traditional API integrations where a human reviews the data, MCP tool calls happen autonomously.

Practical security guidance

Least privilege, always. Grant the minimum permissions each MCP Server needs. If you only need read access to a repo, don't grant write access. Review Connector permissions before granting them. This applies to both custom servers and managed Connectors.

Validate inputs and outputs. Custom MCP Servers should validate every input from Claude and sanitize every output returned to Claude. Don't assume Claude will always send well-formed requests, and don't assume external data is safe to pass through raw.

Audit tool calls. Because MCP standardizes the interface, you can build consistent logging across all tool calls. Log what was called, what arguments were passed, and what was returned. This matters for both security monitoring and debugging.

Prefer managed Connectors for sensitive services. Anthropic's Connectors go through security review. A random MCP Server you found on GitHub last week hasn't. For high-stakes integrations (email, financial data, production databases), the managed option is meaningfully safer.

Isolate MCP sessions. Don't connect twenty MCP Servers to the same Claude session if they don't all need to be there. Each additional server increases the attack surface for cross-tool prompt injection.

For a deeper dive on MCP security patterns, including OAuth 2.1, token scoping, and gateway architectures, see our MCP Advanced Patterns article.

Where MCP is heading

MCP is evolving from a wire protocol into a full application platform -- the progression from raw servers to managed Connectors to interactive Apps is the trajectory, and enterprise governance is the next frontier. With 97 million+ downloads, Linux Foundation governance, and adoption by every major AI platform, the standard itself is settled. What's changing is what you can build on top of it.

Three trends to watch:

From protocol to platform

When you can design in Figma, manage projects in Asana, and query data in Hex — all inside a conversation with Claude — the AI assistant starts to look like an operating system, and MCP Servers start to look like its apps.

The Apps model means third-party developers can build rich, interactive experiences that live inside AI conversations. It's the same trajectory that turned web browsers from document viewers into application platforms. HTTP didn't change. What people built on top of it exploded.

Cross-platform convergence

Today, Connectors and Apps are Claude-specific. But the underlying protocol is universal. There's nothing preventing OpenAI from building their own Connector-style managed layer on top of MCP, or Google from adding App-like interactive rendering to Gemini. The protocol is shared; the product experiences will differentiate.

For developers, this means building on MCP is a safe bet regardless of which AI platform wins. Your custom MCP Servers work everywhere. And the patterns you learn — tool design, resource exposure, auth flows — transfer directly to whatever managed ecosystem emerges.

Enterprise MCP governance

As companies connect production systems to AI agents via MCP, governance becomes critical. Which MCP Servers are approved for use? Who can grant Connector permissions? How are tool calls audited? These are the same questions enterprises asked about cloud APIs a decade ago, and the answers will look similar: approved registries, access policies, centralized logging.

The Connectors model actually helps here. Managed Connectors with standardized permissions are easier to govern than a sprawl of custom MCP Servers. Expect enterprise-tier Connector management -- admin controls, usage analytics, compliance reporting -- to be a major focus through 2026.

Putting it all together

The external layer of the Claude extension stack is a hierarchy, not a flat list. Custom MCP Servers give you unlimited flexibility. Connectors give you managed convenience. Claude Apps give you interactive richness. Each layer builds on the one below it.

The practical takeaway: always start at the top of the hierarchy. Check if a Claude App exists for your use case. If not, check the Connectors Directory. Only build a custom MCP Server when neither managed option covers your needs. This saves weeks of engineering that you can spend on the parts of your product that actually differentiate you.

In Part 4 of this series, we'll bring everything together — Rules, Hooks, Skills, MCP Servers, Connectors — into a real production walkthrough. You'll see exactly how these layers compose to create a Claude development environment that's genuinely customized to your team's workflow.

If you're catching up on the series: Part 1 covers the mental model and decision framework for the entire extension stack. Part 2 dives deep into the internal layers — CLAUDE.md, Hooks, and Skills. And if you want hands-on MCP implementation details, our MCP from Scratch tutorial walks through building a working server in TypeScript and Python.

Learn Agentic AI

One lesson a week — practical techniques for building, testing, and shipping AI agents. From prompt engineering to production monitoring. Learn by doing.

Subscribe

500+ engineers subscribed