Custom Connectors for Your Team
Swipe to show menu
Core Concept
You're probably not going to build a custom connector yourself, unless you're a developer. But you are the person who's going to ask for one. And asking well is its own skill. This chapter is about knowing what's possible, what to brief your team on, and what a good first custom connector looks like.
How It Works (Step-by-Step)
Step 1 - Know when custom is the right call
Three flavors of "custom."
Your company's own dashboard, database, or analytics layer. No official connector exists and never will, because it's yours.
You use a CRM, but you've heavily customized it, and the off-the-shelf connector doesn't cover your fields.
An industry-specific tool nobody's wrapped yet.
In all three cases, custom is the path.
Step 2 - Understand the enabling standard
MCP - Model Context Protocol - is what makes custom possible without waiting on Anthropic. It's an open standard. Anyone can wrap any tool in MCP, and Cowork will talk to it. Your dev team doesn't need permission. They just need to build it.
Step 3 - Brief specifically
The specificity of your ask determines whether the connector ever ships. Bring your dev team five things.
- Tool. Name the system, name the API, name the version.
- Actions. Exact list of what needs to be exposed. "Read contact records," "add a note to a deal."
- Data shape. Which fields, which records, in what format.
- Auth. OAuth, API key - they probably already know.
- First use case. A concrete Cowork task you want to run end-to-end using this connector.
Without that fifth one, the connector drifts into "do everything," which means it ships never.
Step 4 - Pick a good first target
Three rules for the first internal connector.
- Narrow. One tool, a handful of actions.
- Frequent. Something the team interacts with daily.
- Read-mostly. Start with pulling information out. Writes are higher-stakes and need more guardrails.
Step 5 - Set realistic expectations
A focused custom connector is a minutes-to-hours build, not a weeks-long project. Your dev team is wrapping a handful of API endpoints in MCP - not building an app. A dev who has done it once can turn most simple internal tools around in an afternoon. There's ongoing maintenance when the underlying tool's API changes, but that's true of every integration. Once it ships, it pays back the day it lands and every day after that.
Why This Matters
The teams that win with Cowork in the next two years are the teams that started building this internal toolkit early. One custom connector at a time, each scoped narrowly, each shipped in an afternoon. Cowork stops being generic and starts knowing your business.
What Should Be Possible After This
- Identify a candidate for a first custom connector at your company.
- Write a five-point brief a developer could act on.
- Explain what MCP is at a high level to a non-technical colleague.
- Set realistic timeline expectations with your team.
You now have the full extension picture. Native connectors for the big apps. Skills you can install or write yourself. Plugins for bundles. MCP for the community layer. Custom connectors for your team's internal tools. Every workflow from Section 3 onward pulls from this toolkit. Onto files.
Thanks for your feedback!
Ask AI
Ask AI
Ask anything or try one of the suggested questions to begin our chat
Custom Connectors for Your Team
Core Concept
You're probably not going to build a custom connector yourself, unless you're a developer. But you are the person who's going to ask for one. And asking well is its own skill. This chapter is about knowing what's possible, what to brief your team on, and what a good first custom connector looks like.
How It Works (Step-by-Step)
Step 1 - Know when custom is the right call
Three flavors of "custom."
Your company's own dashboard, database, or analytics layer. No official connector exists and never will, because it's yours.
You use a CRM, but you've heavily customized it, and the off-the-shelf connector doesn't cover your fields.
An industry-specific tool nobody's wrapped yet.
In all three cases, custom is the path.
Step 2 - Understand the enabling standard
MCP - Model Context Protocol - is what makes custom possible without waiting on Anthropic. It's an open standard. Anyone can wrap any tool in MCP, and Cowork will talk to it. Your dev team doesn't need permission. They just need to build it.
Step 3 - Brief specifically
The specificity of your ask determines whether the connector ever ships. Bring your dev team five things.
- Tool. Name the system, name the API, name the version.
- Actions. Exact list of what needs to be exposed. "Read contact records," "add a note to a deal."
- Data shape. Which fields, which records, in what format.
- Auth. OAuth, API key - they probably already know.
- First use case. A concrete Cowork task you want to run end-to-end using this connector.
Without that fifth one, the connector drifts into "do everything," which means it ships never.
Step 4 - Pick a good first target
Three rules for the first internal connector.
- Narrow. One tool, a handful of actions.
- Frequent. Something the team interacts with daily.
- Read-mostly. Start with pulling information out. Writes are higher-stakes and need more guardrails.
Step 5 - Set realistic expectations
A focused custom connector is a minutes-to-hours build, not a weeks-long project. Your dev team is wrapping a handful of API endpoints in MCP - not building an app. A dev who has done it once can turn most simple internal tools around in an afternoon. There's ongoing maintenance when the underlying tool's API changes, but that's true of every integration. Once it ships, it pays back the day it lands and every day after that.
Why This Matters
The teams that win with Cowork in the next two years are the teams that started building this internal toolkit early. One custom connector at a time, each scoped narrowly, each shipped in an afternoon. Cowork stops being generic and starts knowing your business.
What Should Be Possible After This
- Identify a candidate for a first custom connector at your company.
- Write a five-point brief a developer could act on.
- Explain what MCP is at a high level to a non-technical colleague.
- Set realistic timeline expectations with your team.
You now have the full extension picture. Native connectors for the big apps. Skills you can install or write yourself. Plugins for bundles. MCP for the community layer. Custom connectors for your team's internal tools. Every workflow from Section 3 onward pulls from this toolkit. Onto files.
Thanks for your feedback!
