The MCP Connector Ecosystem
In Lesson 3, you saw that connectors are the integration infrastructure of a Cowork plugin — declared in the .mcp.json file, they wire the agent to enterprise systems by handling authentication and translating data into formats the agent can reason over. That lesson established what connectors do. This lesson maps what connectors exist.
Anthropic launched the Cowork plugin ecosystem with 11 official plugins in January 2026, expanding to 24 by February 2026. These plugins — available at claude.com/plugins and published in the knowledge-work-plugins repository — span productivity, sales, customer support, product management, marketing, legal, finance, data analytics, enterprise search, and bio-research domains. Each plugin bundles connectors to the enterprise systems that domain requires.
The question every domain professional asks when designing their agent is whether the system they most need to integrate with is already connected. For most enterprise environments, the answer is yes. For systems genuinely specific to your organisation's configuration or industry tooling, there is a commissioning process. Understanding both sides of this picture is the prerequisite for building a realistic deployment plan.
This lesson is a reference lesson. The connector table is designed to be consulted, not memorised. What you should take from it is the landscape — which categories of integration exist, what access types they provide, and where the official ecosystem's coverage ends.
The Official Connector Ecosystem
The connectors below represent the verified ecosystem as of February 2026, drawn from Anthropic's official plugin announcements and the knowledge-work-plugins repository. Connectors are declared in the plugin's .mcp.json file and configured by IT — the knowledge worker specifies what they need in plain language, and the technical implementation follows.
Core Enterprise Connectors
These connectors appear across multiple official plugins and cover the systems found on most enterprise software inventories:
| Category | Connector | Access Type | Key Feature / Note |
|---|---|---|---|
| CRM / Sales | HubSpot | Read/Write | Custom field mapping supported |
| CRM / Sales | Clay | Read/Write | Prospect databases and enrichment workflows |
| CRM / Sales | ZoomInfo | Read | Contact and company enrichment data |
| CRM / Sales | Close | Read/Write | Sales pipeline management |
| Communication | Gmail | Read + Write (drafts/sending) | Scoped to specified mailboxes and threads only |
| Communication | Slack | Read/Write | Channel and thread scoping |
| Communication | Microsoft 365 | Read/Write | Email, calendar, and document access |
| Knowledge / Document | Notion | Read | Folder-level and site-level scoping |
| Knowledge / Document | Google Drive | Read | Folder-level scoping, Google Workspace integration |
| Knowledge / Document | Box | Read | Enterprise content management |
| Knowledge / Document | Egnyte | Read | Hybrid cloud content platform |
| Data / Analytics | Snowflake | Read | Row-level security supported |
| Data / Analytics | Databricks | Read | Lakehouse analytics |
| Data / Analytics | BigQuery | Read | Parameterised query execution |
| Data / Analytics | Amplitude | Read | Product analytics and user behaviour data |
| Workflow / Project | Jira | Read/Write | Issue creation, comments, status transitions |
| Workflow / Project | Linear | Read/Write | Issue and project management |
| Workflow / Project | Asana | Read/Write | Task and project tracking |
| Workflow / Project | monday.com | Read/Write | Work management platform |
| Workflow / Project | ClickUp | Read/Write | Project management and collaboration |
| Design / Creative | Figma | Read | Design file access and component inspection |
| Design / Creative | Canva | Read/Write | Design creation and template management |
| Development | GitHub | Read/Write | Repository, issue, and PR management |
Domain-Specific Connectors
These connectors serve specific industry verticals and are bundled with Anthropic's domain-focused plugins:
| Category | Connector | Plugin Context | Key Feature / Note |
|---|---|---|---|
| Financial Data | LSEG | Finance plugin | Market data and financial analytics (London Stock Exchange Group) |
| Financial Data | S&P Global | Finance plugin | Credit ratings, market intelligence — licensed subscription required |
| Financial Data | FactSet | Finance plugin | Financial data and analytics — licensed subscription required |
| Financial Data | MSCI | Finance plugin | ESG and index data — licensed subscription required |
| Legal | LegalZoom | Legal plugin | Legal document workflows |
| Legal | DocuSign | Legal plugin | Contract workflows, signature status, document repositories |
| Bio-Research | PubMed | Bio-research plugin | Biomedical literature search |
| Bio-Research | ClinicalTrials.gov | Bio-research plugin | Clinical trial registry and results database |
| Bio-Research | ChEMBL | Bio-research plugin | Chemical and bioactivity database |
| Bio-Research | Benchling | Bio-research plugin | Life science R&D platform |
| Bio-Research | BioRender | Bio-research plugin | Scientific illustration and figure creation |
| Contracting / Signature | DocuSign | Multiple plugins | Contract workflows and e-signature |
| Enterprise Search | (plugin-managed) | Enterprise-search plugin | Cross-system search using tool-agnostic placeholder pattern |
A notable pattern in the official repository is the tool-agnostic placeholder: several plugins define connector slots that can be filled with whichever system the enterprise uses. The enterprise-search plugin, for example, defines search capabilities without hardcoding a specific search provider — the organisation plugs in their own.
What the Ecosystem Covers
The CRM and sales connectors — HubSpot, Clay, ZoomInfo, Close — cover the major sales workflow systems. The communication connectors — Gmail, Slack, Microsoft 365 — handle the messaging platforms found in most enterprises. Knowledge connectors — Notion, Google Drive, Box, Egnyte — provide access to document repositories with folder-level and site-level scoping.
The data and analytics connectors — Snowflake, Databricks, BigQuery, Amplitude — provide read access to data warehouses and analytics platforms. Snowflake additionally supports row-level security, meaning data access can be governed at the row level according to existing security policies.
The workflow connectors — Jira, Linear, Asana, monday.com, ClickUp — cover the major project management platforms. An agent can read sprint status, create follow-up tickets, or track task completion across these systems.
For financial services, the LSEG, S&P Global, FactSet, and MSCI connectors provide access to market data, credit analytics, ESG scores, and index data. A critical dependency applies here: these connectors require the organisation to already hold licensed subscriptions to the respective data services. The MCP connector provides the integration layer — it does not grant access to data the organisation has not licensed.
For bio-research, the PubMed, ClinicalTrials.gov, ChEMBL, Benchling, and BioRender connectors support literature search, trial registry access, chemical databases, R&D platforms, and scientific illustration — covering the core workflow of life science research teams.
For legal workflows, LegalZoom and DocuSign cover document creation and contract execution. Box and Egnyte serve as document management systems commonly used in legal departments for secure file storage and sharing.
Custom Connectors: When the Marketplace Does Not Cover Your System
The marketplace covers the systems that appear on most enterprise software inventories. But enterprise environments are not homogeneous. Many organisations run systems that are either too niche for a generalised connector to be viable, or configured in ways that are specific enough to require a connector built for their particular installation.
The Revit connector listed in the table is an example. Revit is Autodesk's building information modelling software, used heavily in architecture, engineering, and construction. There is no generalised Revit connector in the marketplace, because each organisation's Revit environment is structured differently — different project hierarchies, different custom parameters, different data schemas. A developer builds a custom Revit MCP server tailored to the specific organisation's Revit installation, exposing BIM data as queryable structured data. The knowledge worker who uses that connector experiences it the same way as any marketplace connector — they specify what they need in their SKILL.md and the agent queries it — but the connector itself was built specifically for their environment. Chapter 22 covers the construction and engineering domain in detail, including the Revit connector architecture.
The commissioning process for a custom connector follows a consistent pattern. The knowledge worker specifies what they need in plain language: which system to connect to, what data should be accessible, what query types the agent will need to run, and what permissions are appropriate. The developer takes that specification and builds. The knowledge worker does not write code; they write requirements.
A sufficient plain-language specification addresses four questions:
Which system? Name the system precisely, including the version if relevant. "Our on-premises SAP S/4HANA instance at [environment]" is more useful than "SAP."
What data? Specify the data objects or entities the agent needs access to. "Open purchase orders, vendor master records, and goods receipt confirmations" is more useful than "procurement data."
What queries? Describe the types of questions the agent will need to ask. "Filter purchase orders by vendor and date range," or "retrieve all open approvals assigned to a specific cost centre." The developer uses these to design the query API.
What permissions? Specify read-only or read-write, and any row-level or scope restrictions that should apply. If the agent should only see purchase orders above a certain value threshold, or only within a specific regional entity, that constraint belongs in the specification.
Timeline Expectations
Custom connector development timelines depend on the underlying system's API maturity. Systems with well-documented REST APIs, active developer communities, and clear authentication flows are significantly faster to integrate than legacy systems with sparse documentation, older protocols, or custom schemas that require reverse-engineering.
The key planning insight is that connector commissioning is on the critical path. A plugin that requires a custom connector cannot go live until that connector is built and tested. Connector commissioning and SKILL.md development can run in parallel — but connector commissioning must start first, because it typically takes longer. Work with your IT team to estimate timelines based on the specific system's characteristics rather than applying generic benchmarks.
Try With AI
Use these prompts in Anthropic Cowork or your preferred AI assistant to apply the connector ecosystem to your domain.
Prompt 1: Map Your Domain's Connector Needs
I work as [YOUR ROLE] in [YOUR DOMAIN/INDUSTRY]. Based on the MCP connector ecosystem described in this lesson, help me identify which connectors would be most relevant to my work.
For each connector category (CRM, communication, knowledge/document, data/analytics, workflow, financial, legal, clinical, contracting, enrichment), tell me:
1. Whether it's likely relevant to my domain
2. What specific workflows I might use it for
3. Any licensing or configuration requirements I should be aware of
Then identify which of my important systems are NOT covered by the marketplace, and would require custom connector commissioning.
What you're learning: How to translate the connector table from an abstract reference into a concrete picture of your own agent's integration requirements. The goal is to leave this exercise with a clear view of which connectors you need, which are available, and which require commissioning.
Prompt 2: Draft a Custom Connector Specification
I need to commission a custom MCP connector for [DESCRIBE YOUR SYSTEM: name, version, whether it's cloud or on-premises, what kind of data it holds].
Help me write a plain-language connector specification that covers the four required elements:
1. System identification (precise system name, version, environment)
2. Data objects needed (specific entities or data types the agent should access)
3. Query types (the questions the agent will need to ask — filter by X, retrieve by Y, etc.)
4. Permission scope (read-only or read-write, any row-level or entity-level restrictions)
Ask me clarifying questions if you need more information. The output should be a specification I can hand to an IT developer.
What you're learning: How to produce an actionable connector specification rather than a vague request. The difference between "I need access to our CRM" and a specification that a developer can build from is the difference between a connector that takes eight weeks and one that takes two.
Prompt 3: Build a Connector Deployment Timeline
I'm planning to deploy a Cowork plugin for [YOUR USE CASE]. The plugin will need the following connectors:
[LIST YOUR CONNECTORS — include both marketplace connectors you've identified and any custom connectors you need]
For the custom connectors, I believe the underlying systems are: [describe each system's API maturity — modern REST API, or older/legacy system].
Help me build a realistic deployment timeline that:
1. Identifies which connectors can be activated immediately (marketplace)
2. Estimates development effort for custom connectors based on API maturity
3. Puts connector commissioning on the critical path appropriately
4. Identifies any licensing requirements that must be resolved before connector activation
What you're learning: How to build a realistic deployment plan that treats connector timelines as planning facts rather than optimistic estimates. Connector dependencies are frequently the longest lead-time item in a plugin deployment — mapping them early prevents planning surprises.
Flashcards Study Aid
Continue to Lesson 7: The Governance Layer →