Claude Connectors vs. MCP Servers vs. the MCP Connector API

The word "connector" does triple duty around Claude, and the three things it names aren't variations on a theme. They're separate products, they run in different places, and different people build them:

1. Claude Connectors are the integrations a Claude user switches on inside their account. Each one is backed by a remote MCP server, and the user experience is a toggle, not a config file.
2. The MCP connector is a feature of the Messages API on the Claude Developer Platform. It lets your code attach a remote MCP server to a single API request without you implementing an MCP client at all.
3. "MCP connector" is also used loosely across the industry to mean "an MCP server," or "the thing in our product that talks to an MCP server." Microsoft, OpenAI, and a long list of SaaS vendors all use it this way.

The docs for the first two live on different documentation sites (claude.com/docs for the product, platform.claude.com/docs for the API), and neither is written for the other's audience, so landing on the wrong one tells you nothing about your actual question.

The three, side by side

Claude Connectors: the thing in a Claude account

Connectors extend Claude by giving it tools and data from outside services, and they're powered by MCP (Connectors overview). Some are first-party (Gmail, Google Drive, GitHub, Slack, Microsoft 365), some come from the Connectors Directory, and some you add yourself by pasting in a URL.

The directory labels every entry so users know how much review it's had. The labels describe review, not technology:

• Verified means Anthropic reviewed it for quality and security. It gets a checkmark next to its name.
• Community means a third-party developer built it and it passed Anthropic's automated checks, but Anthropic hasn't reviewed it in depth.
• Custom means you added it yourself and Anthropic hasn't reviewed it at all.

All three run the same way. Anthropic is explicit about this: directory and custom connectors "run on the same MCP infrastructure. The runtime, transport, authentication, and tool-calling code paths are identical," and the label affects discovery and display rather than how the connector functions (directory vs custom, connector verification). What listing does buy you is real but narrow: in-product browse and search, eligibility for Suggested Connectors, Anthropic-held client credentials, and the ability to allowlist external link destinations so users skip a confirmation modal.

Adding a custom one is a URL paste, with a plan-shaped wrinkle. On Free, Pro, and Max you add it in your own connector settings; on Team and Enterprise an Owner adds it to the organization first, and members then click Connect to authenticate individually. Custom connectors work on Free (limited to one), Pro, Max, Team, and Enterprise, across claude.ai, Claude Desktop, Cowork, and mobile (Anthropic support).

Claude reaches your server from Anthropic's cloud

When Claude connects to your remote MCP server, the request originates from Anthropic's infrastructure, not from the user's device. That holds on every client, including Claude Desktop and Cowork, even though those run on the user's own machine (Anthropic support).

Your server therefore has to be reachable over the public internet. Before making any request, Claude resolves your hostname and rejects the connection if any resolved address isn't globally routable, "before any HTTP request leaves Anthropic's network," which means your access logs show nothing and the user sees "Couldn't reach" (connector troubleshooting). A server on a corporate network, behind a VPN, or blocked by a WAF fails the same way. If you must keep it private, the fix is allowlisting Anthropic's published egress range.

That single difference explains the most confusing symptom in the category: the same server answers curl and works in Claude Code, then dies in claude.ai. The CLI connects from your machine; claude.ai doesn't.

Auth is OAuth, unless it isn't

OAuth is the normal path, and if you're building the server, implementing OAuth 2.1 authentication for MCP servers is the work. For servers that authenticate with a fixed API key or bearer token instead, request-header auth is in beta: up to four headers, names restricted to a reviewed allowlist such as authorization, x-api-key, and x-auth-token (third party connectors with remote MCP).

Two details in that beta bite people. Claude sends the value exactly as entered and adds no scheme prefix, so a bearer token has to be typed as Bearer with the trailing space followed by the token. And Authorization can't be configured as a request header on an OAuth connection, because OAuth owns that header. If you want the full build path, see building a custom Claude connector with a remote MCP server.

The MCP connector: a Messages API feature

Different product, different audience, same word. The MCP connector lets you "connect to remote MCP servers directly from the Messages API without a separate MCP client" (MCP connector docs). Nobody enables anything in a UI. You add two things to a request body and Anthropic does the MCP client work on its side.

The two things are an mcp_servers entry describing the connection, and an mcp_toolset entry in the tools array describing which of that server's tools to expose and how:

{
  "model": "claude-opus-5",
  "max_tokens": 1000,
  "messages": [{ "role": "user", "content": "What's blocking the release?" }],
  "mcp_servers": [
    {
      "type": "url",
      "url": "https://mcp.example.com/mcp",
      "name": "example-mcp",
      "authorization_token": "YOUR_OAUTH_ACCESS_TOKEN"
    }
  ],
  "tools": [
    {
      "type": "mcp_toolset",
      "mcp_server_name": "example-mcp",
      "default_config": { "defer_loading": true },
      "configs": { "search_issues": { "enabled": true, "defer_loading": false } }
    }
  ]
}

The request also needs the beta header anthropic-beta: mcp-client-2025-11-20; the earlier mcp-client-2025-04-04 shape, which put tool configuration inside the server definition, is deprecated. Each tool takes enabled and defer_loading, and defer_loading pairs with the Tool search tool: the description isn't sent to the model up front, which keeps a large tool surface out of the context window until it's wanted. Per-tool configs override default_config, so the block above defers everything except search_issues. Every server you define has to be referenced by exactly one toolset, or the API rejects the request.

Results come back as new content block types rather than ordinary tool_use: an mcp_tool_use block carrying the tool name, server_name, and input, and an mcp_tool_result block with is_error and the content. Your code reads those blocks, but never speaks MCP itself.

The constraints are where this diverges hardest from a Claude Connector:

• Tools only. Of the MCP feature set, only tool calls are supported. No prompts, no resources.
• Remote HTTP only. Streamable HTTP and SSE are both accepted, the URL must start with https://, and local stdio servers can't be connected. If that distinction is fuzzy, comparing stdio, SSE, and Streamable HTTP covers it.
• You own the OAuth flow. The API takes an authorization_token and nothing else. Obtaining it and refreshing it are your job.
• Not everywhere. It's available on the Claude API, Claude Platform on AWS, and Microsoft Foundry (Hosted on Anthropic deployments only). It isn't available on Amazon Bedrock or Google Cloud.

When those limits don't fit, the answer isn't to fight the parameter. Anthropic's own guidance is to run a real MCP client and use the SDK's client-side MCP helpers, which convert between MCP types and Claude API types, whenever you need local servers, prompts, resources, or more control over the connection.

When a vendor says "connector" and means "MCP server"

The third meaning is the loosest and the most common outside Anthropic's docs. Microsoft's Copilot Studio routes MCP access through Power Platform connectors, and one of its two documented paths for adding a server is literally "create a custom MCP connector in Power Apps" (Microsoft Learn). OpenAI uses the word for its own hosted integrations: "Connectors are OpenAI-maintained MCP wrappers for popular services like Google Workspace or Dropbox" (OpenAI API docs).

Underneath, none of this is a distinct technology. It's an MCP server speaking JSON-RPC over an HTTP transport, wearing whatever name the host product gave it. Two questions resolve any usage you run into: who initiates the connection (a chat product on a user's behalf, or your own code), and where it's configured (a settings screen, or a request body).

The neighbors: Skills, Plugins, and MCP Bundles

Three adjacent Claude features get folded into connector conversations, and none of them is a connector:

• Skills are directories of instructions and scripts with a SKILL.md that Claude loads when a task matches. They add know-how, not connectivity. Available on Pro, Max, Team, and Enterprise, and they require code execution to be enabled (Skills overview).
• Plugins bundle skills, MCP connector references, slash commands, and sub-agents into one installable package, and they work in Claude Code and Cowork. A plugin references a remote MCP server by URL, and if that URL isn't a directory listing, the connector shows up as Custom in the user's settings (what to build).
• MCP Bundles (MCPB) are .mcpb zip archives containing a local MCP server plus a manifest.json, for single-click install in Claude Desktop (MCPB build guide). The tooling was renamed from DXT: the dxt CLI is now mcpb and .dxt files are now .mcpb files (mcpb repo).

You built an MCP server. Which one do you want?

Route by who is going to use it:

• Your team, or a handful of users, in Claude chat. Add it as a custom connector by URL. On Team or Enterprise, an Owner adds it once for the org and members connect individually.
• Strangers, discoverably. Submit to the Connectors Directory. The runtime doesn't change, so this is a distribution and trust decision rather than a technical one.
• Your own application, calling the Claude API. Use the MCP connector, as long as tools-only over a remote HTTPS server covers your needs. It saves you an entire MCP client implementation.
• Your own application, needing prompts, resources, or a local stdio server. Skip the connector parameter and run a real MCP client with the SDK helpers.
• Local machine access, in a developer's hands. Package it as an MCPB for Claude Desktop, or wire it up through the CLI as in adding an MCP server to Claude Code, which uses a different config model entirely.

If you're picking one thing to build first, we'd build the remote MCP server with OAuth. It's the only artifact every path above shares, and it matches Anthropic's own recommendation that most partners ship a remote MCP server plus a plugin that wraps it with skills.

Where this leaves you

The naming isn't going to improve, so carry a question instead of a vocabulary: who is holding the MCP client? For a Claude Connector, Anthropic holds it and the user grants access. For the Messages API MCP connector, Anthropic still holds it, but your code decides which tools exist on each request. For everyone else's "connector," read their docs, because the word carries no guarantee.

One thing stays constant across all three: you can't see Anthropic's half of the connection. When a connector misbehaves, the only evidence lives on your server, in whether initialize landed, whether tools/list was called, and what arguments arrived with each tool call. That's the visibility AgentCat is built to give MCP servers in production.