Claude's connector directory crossed 400 integrations in 2026, and for most teams that abundance is the problem, not the solution. A list of hundreds of tools sorted alphabetically tells you what exists; it does not tell you which connectors will move a number in your business, how to wire them up safely, or where to start. The useful way to read the ecosystem is not as a catalog but as a map organized by business function — CRM, automation, meetings, data, finance, support, and a dozen more categories that each solve a distinct class of work. This guide lays out that map, explains how the three kinds of connectors actually work, shows the use cases each category unlocks, and describes how to adopt them without creating the integration sprawl that quietly undermines most AI programs.
The Claude connector ecosystem is the directory of 400+ integrations that let Claude read from and act on your business systems through the Model Context Protocol (MCP). Connectors come in three forms: first-party connectors built by Anthropic, partner-built remote MCP servers hosted by the tool vendor, and local or custom MCP servers your own team controls. The strategic way to navigate it is by business function — group connectors into categories like CRM, workflow automation, meeting intelligence, data platforms, and finance, then connect only the few that map to a real workflow, with scoped credentials and governance from day one. Start with the systems where your team already spends its time, prove value on one workflow, then expand category by category.
Claude is Anthropic's AI assistant, and connectors are how it reaches beyond the chat window into the systems where your work actually lives — your CRM, your documents, your meetings, your data warehouse. The connector directory is the catalog of those integrations, and it has grown past 400 entries as more vendors publish official connections.
Underneath nearly all of them sits one open standard: the Model Context Protocol (MCP). MCP is the common language that lets Claude discover what a connected tool can do, request specific data, and take scoped actions — without anyone hand-coding a one-off integration. That standardization is why the directory grew so fast, and it is also why the ecosystem is best understood as a single architecture rather than hundreds of unrelated plugins. For a deeper look at the standard itself, see how MCP servers connect Claude to your systems of record.
The mistake teams make is treating the directory as a shopping list. Four hundred connectors browsed without a plan produces exactly the sprawl that makes AI hard to govern: nobody can say what Claude can reach, which credentials it uses, or what data flows where. The directory is a menu, not a meal — and the value comes from choosing deliberately.
Before mapping the categories, it helps to know that "connector" covers three meaningfully different things. They look similar in the interface but differ in who builds them, who hosts them, and who is responsible for governing them.
| Connector type | Who builds and hosts it | Typical setup | Governance implication |
|---|---|---|---|
| First-party connector | Anthropic | Enable in settings, authenticate via OAuth to the tool | Vendor-maintained; you govern access and scope |
| Partner remote MCP server | The tool's vendor | Add the remote MCP URL, authenticate to the vendor | Vendor hosts; you control which users and what scope |
| Local or custom MCP server | Your team | Run via the desktop app or your own infrastructure | You own the code, hosting, credentials, and audit |
The practical differences that matter:
In every case, the security principle is the same: connect through scoped credentials with least-privilege access, route through approved connectors your team can inventory, and keep the activity in audit logs. The connection layer is where both the value and the risk concentrate, a point we cover in building a secure Claude environment.
Here is the ecosystem organized the way a business should read it — by the work each category does, not by vendor name. Each category becomes its own deep-dive in this series; this hub is the map that ties them together.
| Category | What it connects Claude to | Representative use case |
|---|---|---|
| CRM | Customer and pipeline systems of record | Draft account summaries and update records from a conversation |
| Workflow automation & iPaaS | Cross-app orchestration and integration platforms | Trigger multi-step workflows from a natural-language request |
| Meeting & conversation intelligence | Call recordings, transcripts, notes | Turn a sales call into a summary, next steps, and CRM updates |
| Google Workspace & Google Cloud | Drive, Gmail, Calendar, BigQuery | Pull context from documents and email to draft a reply |
| Microsoft ecosystem | SharePoint, Teams, Outlook, Dataverse | Surface the right document and draft from existing content |
| Sales intelligence & enrichment | Account, contact, and firmographic data | Enrich a lead and prep an outreach plan with current data |
| Project & work management | Tasks, issues, projects, docs | Convert a meeting into assigned, tracked action items |
| Knowledge & collaboration | Wikis, knowledge bases, file stores | Answer questions grounded in internal documentation |
| Marketing automation & email | Campaign and lifecycle platforms | Draft and segment a campaign from existing audience data |
| SEO, AEO & marketing analytics | Search, ranking, and analytics tools | Analyze visibility and brief content from real metrics |
| Customer support & success | Tickets, conversations, health scores | Summarize a ticket history and draft a resolution |
| Finance, accounting & spend | Accounting, billing, and payments systems | Reconcile and explain a financial question with source data |
| Data platforms, warehouses & BI | Warehouses, lakehouses, BI tools | Query governed data in plain language and explain the result |
| Product & web analytics | Usage and behavior platforms | Investigate a usage drop with the underlying event data |
| Documents & e-signature | Contracts, agreements, content systems | Review a contract and extract key terms and obligations |
| Developer tools & cloud infra | Code, errors, deployments, infrastructure | Triage an error with logs and the relevant repository |
| HR, recruiting & people ops | Hiring, payroll, people systems | Screen and summarize candidates against a role |
| Design & creative | Design files, diagrams, creative assets | Generate or summarize visual assets in workflow |
| E-commerce, web & CMS | Storefronts, sites, content platforms | Update product content and answer store-data questions |
| Industry-specific (finance markets, legal) | Specialized data and intelligence providers | Ground analysis in domain data within a governed boundary |
The point of the map is selectivity. A finance team does not need the design category; a marketing team rarely needs market-data terminals. Reading by function lets each team identify the two or three categories that touch their daily work and ignore the rest — which is exactly how you avoid connecting everything and governing nothing.
Across every category, the high-value patterns rhyme. Connectors are worth wiring up when they collapse one of these recurring frictions:
The unifying theme: connectors are valuable when they put real business context in front of the model. That is also why they are risky if built carelessly — the same access that makes Claude useful makes scope and governance non-negotiable.
Every connector you enable is a data-access decision. Before connecting a category, answer four questions:
These are not category-specific exotica; they are the same four controls applied consistently. A governed environment is what lets you say yes to new connectors quickly, because the rules already exist. Building that governance is covered in building a secure Claude environment.
The common thread is that none of these are model failures. They are integration-governance failures, and they are cheap to prevent and expensive to retrofit — the same lesson companies learned scaling earlier AI pilots, covered in why AI pilots fail.
This sequence is why a strategic map matters more than the connector count. The directory will keep growing; the discipline of connecting by function, one governed workflow at a time, is what turns 400+ options into a working system.
Vantage Point helps companies turn the connector ecosystem from a sprawling directory into a governed, value-producing layer — with senior consultants on every engagement, no junior staff learning on your project. A typical engagement maps your business functions to the right connector categories, designs the scoped-credential and least-privilege architecture, builds the connections to your systems of record, and verifies governance and audit before usage scales.
The integration work runs through system integration and data migration; the access, classification, and audit work runs through compliance and security solutions; and the ongoing health of the connector layer runs through managed services and ongoing support. Because the practice is vendor-agnostic and dual-platform, the connector strategy fits whether you run on Salesforce, HubSpot, or both — and it is built to hand over with documentation and a named internal owner, not to create dependency.
The connector directory has grown past 400 integrations in 2026 and continues to expand as more vendors publish official connections. The exact count changes frequently, so treat any specific number as a snapshot and verify current availability for the specific tools you need at adoption time.
They are closely related. Most Claude connectors are built on the Model Context Protocol (MCP), the open standard that lets Claude discover a tool's capabilities and request scoped data or actions. A "connector" is the user-facing integration; an "MCP server" is the underlying component — built by Anthropic, the tool's vendor, or your own team — that exposes those capabilities.
Not for every connector. Many remote connectors are available on paid tiers, but admin-managed connectors, organization-wide controls, and the ability to restrict which connectors users can enable generally require a business-grade tier such as Team or Enterprise. Confirm the current plan requirements for the connectors you intend to govern.
Start where your team already spends its time assembling context or updating records — usually CRM, meeting intelligence, and workflow automation. Connect only the connectors a single, high-frequency workflow needs, prove value, then expand to the next category. Connecting by business function beats connecting by availability.
It is safe when the connection is scoped. Use a least-privilege account that can reach only the objects the workflow needs, honor the source system's sharing model, classify the data, and keep activity in audit logs. The risk comes from over-permissioned accounts and ungoverned connections, not from the connection itself.
When no published connector fits, your team can run a local MCP server through the desktop app or build a custom MCP server against your own systems. This is the most flexible option and requires the most governance, because you own the credentials, hosting, and audit trail.
The connector architecture is the same; the permission model differs. Salesforce expresses least privilege through profiles, permission sets, and field-level security, while HubSpot uses seats, permission sets, and scoped private apps. Either way, Claude's access to CRM data should be a deliberate, scoped, logged decision rather than a side effect of whichever credential was available.
Maintain an approved-connector list, use admin controls on a business-grade tier to limit what users can enable, scope every connection to least privilege, and review connector activity periodically. Govern the connector layer like any other production integration, with a named owner responsible for its health.