MCP connectors — bringing your SaaS into Claude Cowork

TL;DR. The Model Context Protocol is what lets Cowork talk to your other software. Cowork on local files is useful; Cowork on local files + Slack + GitHub + Notion + Salesforce + your warehouse is transformative. Use official connectors where they exist, build custom ones for the systems your team actually lives in, and wait on the systems where the API is changing weekly.

What MCP is, in one paragraph#

The Model Context Protocol is an open standard from Anthropic that lets AI agents talk to other software in a structured way. A connector is a small server that speaks MCP on one side and a vendor's API on the other. Once installed, Cowork can use the vendor's product as if it were another tool — the same way it uses local files. For the deeper protocol-level explanation see What is MCP; this page is about what to do with it.

The mid-market lens#

Cowork on files alone is useful. Cowork on files plus the four or five systems your team uses every day is a different category of tool. MCP is the line that crosses.

The reason this matters specifically at mid-market: a 200-person company already has the SaaS sprawl that connectors are designed to bridge. You bought CRM, ticketing, knowledge base, finance, and HR over five years; nobody's job is to glue them together. MCP is the glue layer that does not require an integration team.

Connectors that ship today#

A representative list — verify against current Anthropic docs because the catalogue moves weekly.

Productivity — Google Workspace, Microsoft 365, Notion, Slack, Linear, Asana, Trello, Airtable. CRM — HubSpot, Salesforce. Engineering — GitHub, GitLab, Jira. Data — Postgres, Snowflake, BigQuery (mostly community). Finance / Ops — Stripe, Qonto, QuickBooks (community).

Each connector has a vendor, a status (official or community), an auth model (OAuth or API key), and a permission scope. We re-test the catalogue monthly and publish deltas in the Changelog.

What "custom MCP connector" means#

A custom MCP connector is a server Tinkso (or your engineering team) builds to wrap an internal API or a SaaS that does not yet have an official connector.

Common examples in mid-market:

• ERP — NetSuite, Sage, Microsoft Dynamics. The system that owns the numbers always tops the list.
• Data warehouse — read-only access to your warehouse for synthesis prompts.
• Internal billing system — usually homegrown, always undocumented.
• Custom CRM or operational platform — the one your team uses ten times a day that nobody else has.

Engagement shape: roughly two to four weeks per connector, including security review. Most clients build one to three custom connectors per engagement. See the MCP connectors service for the build process and pricing.

Security model for connectors#

• Each connector runs with explicit user-granted permissions.
• OAuth is preferred over API keys; API keys, when unavoidable, are stored in the platform's vault.
• A connector can only do what its permissions allow. Cowork inherits the user's scope — it cannot escalate.
• Audit logging depends on the connector vendor and the underlying SaaS. For regulated environments we wire connectors to push audit events to a central SIEM.

For the broader access model see Access & folder policy.

The "files + connector" pattern#

Most mid-market wins come from combining a connector with the local workspace, not from either alone.

• Connector pulls live data — current account list from CRM, last week's customer tickets from Zendesk, this month's invoices from the finance system.
• Cowork synthesises in the workspace folder, applying the team's CLAUDE.md for tone, schema, and naming.
• Output lands in output/ as a Word, Excel, or PowerPoint artifact the team can hand off without copy-paste.

Live data plus polished artifact plus no copy-paste equals the workflows that actually save the four-to-eight hours per week per role we see in deployments. Either piece alone underwhelms.

When to build vs buy vs wait#

The most common Tinkso recommendation is "buy what's official, build the one connector that matters most for the pilot function, defer everything else for ninety days." Trying to build five connectors at once is a great way to ship none.

Tinkso's take#

Custom MCP connectors are the single most leveraged piece of work in our engagements. We have seen clients spend $40k on a Cowork rollout where a $12k connector unlocks roughly three times the value because it ties Cowork to the system the team actually lives in. The Observe beat of our method is largely about identifying the connector candidates worth building — the systems whose absence is what makes file-only Cowork feel under-powered.

The other thing custom connectors enable is honest scoping: when the team can name exactly which API calls Cowork will make, the security review becomes a one-week review instead of a quarter-long one.

Try this#

List the five SaaS apps your pilot team uses daily. Mark each one: Official today / Community / Coming on roadmap / Custom build needed. That list is your connector roadmap. The first connector to build is whichever one would unlock the highest-frequency workflow on the pain/gain map from week one of the rollout.