First-Party vs MCP-Based Connectors: What's the Difference
Once you decide to connect a company data source to Claude, you will run into two different kinds of connector.
//
Search across all documentation pages
Once you decide to connect a company data source to Claude, you will run into two different kinds of connector.
Some are described as first-party, and others as MCP-based.
From inside a conversation, both look and behave almost identically: Claude searches a source and cites what it finds.
The real difference is underneath, in who built and maintains the integration, and that difference has practical consequences for coverage and reliability.
A first-party connector is an integration that Anthropic designs, builds, and maintains directly.
Google Drive, Slack, and Notion are examples of tools commonly reached this way, because they are common enough that Anthropic has invested in a dedicated, native integration for each.
An MCP-based connector reaches a tool through the Model Context Protocol, an open standard for connecting an AI assistant to external tools and data sources.
Because MCP is open, anyone, including a tool vendor or a third-party developer, can build a server that exposes their tool to Claude through this protocol.
The simplest way to think about the difference: first-party connectors are Anthropic's own work, and MCP-based connectors are a plug that lets other people's work connect to Claude using a shared standard.
Both kinds ultimately do the same job for the person using Claude: they let Claude search a company's data source and answer with citations back to it.
Under the hood, the two paths differ in ownership more than in behavior.
A first-party connector ships as part of Claude's own product surface, so its permission model, error handling, and search quality are tuned and updated by Anthropic directly.
An MCP-based connector runs against a separate MCP server, which might be operated by the tool vendor, by a third-party integrator, or in some cases by your own organization.
First-party: Claude <--> Anthropic-built connector <--> Tool (e.g. Google Drive)
MCP-based: Claude <--> MCP protocol <--> MCP server (vendor/third-party/self-hosted) <--> Tool
That extra hop for MCP-based connectors is not a performance concern in normal use, but it does mean an additional party is now part of the chain.
If an MCP server goes down, changes its behavior, or is deprecated, that is outside Anthropic's direct control, whereas a first-party connector's lifecycle is entirely Anthropic's responsibility.
Permission scopes work the same way regardless of connector type: whichever kind of connector you use, it can only search the folders, channels, or records it has been explicitly authorized against.
For an organization choosing between the two, the decision usually comes down to coverage versus maintenance ownership.
If the tool you need is one of the common ones Anthropic already supports natively, a first-party connector is generally the simpler and lower-maintenance choice.
If you need a specialized or internal tool that has no first-party option, an MCP-based connector may be the only way to reach it, and its reliability then depends on whoever operates that MCP server.
| Approach | Strength | Weakness | Best Fit |
|---|---|---|---|
| First-party connector | Maintained directly by Anthropic, consistent update cadence | Limited to tools Anthropic has chosen to build native support for | Common, widely used tools like Drive, Slack, or Notion |
| MCP-based connector | Extends coverage to virtually any tool with an MCP server | Reliability and support depend on the server's operator, not Anthropic | Specialized, internal, or less common tools |
Because MCP-based connectors can be built and hosted by parties outside Anthropic, it is worth treating them with the same scrutiny you would apply to any third-party integration: know who runs the server, what data it can see, and how it is kept up to date.
This is one more reason permission scopes matter regardless of connector type, since a narrow scope limits exposure even if the integration itself is less familiar than a first-party one.
First-party connectors are built and maintained by Anthropic. MCP-based connectors are built using the open Model Context Protocol, often by the tool vendor or a third party. Both let Claude search outside data.
Not meaningfully. Both let Claude search a connected source and cite it. The practical differences show up in coverage and long-term maintenance, not in how a normal search feels to the user.
MCP is an open protocol that lets an AI assistant like Claude connect to external tools and data sources through a standard interface, which is what makes MCP-based connectors possible.
Anthropic builds and maintains first-party connectors directly, as part of Claude's own product.
The tool vendor, a third-party developer, or in some cases your own organization, depending on who built and hosts the specific MCP server being used.
Often, yes, since it removes an extra party from the chain and is maintained directly by Anthropic. But this is not an absolute rule; the right choice depends on your specific needs and the maturity of the available MCP alternative.
No. Both connector types are limited by the permission scope they were authorized against, whether they were built by Anthropic or reached through MCP.
Yes. Anthropic can add native support for new tools over time, which can move a tool from MCP-only to also having a first-party option.
No. Regardless of connector type, Claude attributes answers back to the specific documents or records it used, so citations work the same way either way.
The dedicated page on connector permission scopes covers how scoping works in more detail, including how narrower scopes reduce risk for either connector type.
Stack versions: Written against the Claude model lineup current as of ~June 2026 - Claude Fable 5, Claude Opus 4.8, Claude Sonnet 5 (the default), and Claude Haiku 4.5. Model names, pricing, and product features move quickly - verify current specifics at platform.claude.com/docs before relying on them.
Reviewed by Chris St. John·Last updated Jul 16, 2026