Guide
Custom connectors on Claude Team and Enterprise plans
One connector, a whole workspace. Here is how custom connectors work on Claude's paid team plans, and what a rollout actually involves, from a team that builds them for clients.
Claude's paid team plans support custom connectors backed by remote MCP servers. An org admin controls which connectors are enabled for the workspace, and each user authenticates to the underlying tool as themselves, so permissions stay per-user. A hosted remote server is what lets one connector serve the entire team.
Key takeaways
- Custom connectors on team plans are backed by remote MCP servers, hosted somewhere every member can reach, not local processes on each laptop.
- Org admins decide which connectors are available to the workspace, which gives IT a real control point instead of per-user sprawl.
- Each user signs in to the connected tool as themselves, so Claude only ever sees what that person is already allowed to see.
- Check the Claude Help Center for current plan features; plan details change faster than blog posts do.
Do Claude Team and Enterprise plans support custom connectors?
Yes. Claude's paid team plans support custom connectors backed by remote MCP servers, alongside the built-in connectors in the directory. The exact features of each plan evolve, so treat the Claude Help Center as the authority on what your plan includes today rather than any third-party summary, including this one.
The important architectural fact is stable even as plan details shift: a custom connector on a team plan is a remote MCP server that Claude connects to over the network. That is what makes it shareable across a workspace at all.
We build and host these servers for client teams, so the rollout guidance in this post is first-hand rather than paraphrased documentation. For plan specifics, entitlements, and current UI, the Claude Help Center is the source of truth.
How do org admins control which connectors a team can use?
Admins enable connectors at the workspace level, deciding which ones members can use. That turns connectors from a per-user free-for-all into something IT can review and approve once, centrally. A connector an admin has not enabled simply is not available to the workspace, which is the control surface security teams ask for.
In practice this changes who the connector conversation is with. On a personal plan, an individual adds whatever they want. On a team plan, a connector goes through whoever administers the workspace, which usually means a short review: what the server can read, what it can write, where it is hosted, and how it authenticates.
For a custom connector, that review is much easier when the server is built with clean answers ready: separated read and write tools, confirmation gates on destructive actions, and per-user authentication. Our connector security checklist covers the questions an admin should ask before enabling anything.
How does authentication work for each team member?
Each user authenticates to the connected tool as themselves, typically through the tool's own OAuth sign-in the first time they use the connector. Claude then acts with that person's permissions, no more. A manager and a new hire using the same connector see different data, because the underlying tool decides what each account can access.
This is the property that makes team connectors safe to roll out. There is no shared service account whose access everyone silently inherits, and no connector-side permission model to keep in sync with the real one. The tool's existing permissions keep doing their job.
It also keeps the audit trail honest: actions taken through the connector are attributable to the person whose account performed them, not to a bot user shared by the whole workspace.
Why does a team connector need a hosted remote server?
Because everyone in the workspace has to reach the same server. A local MCP server runs on one person's machine and serves that person. A remote server runs on infrastructure with a stable URL, handles each user's OAuth, and stays up whether or not any laptop is open. One hosted server is what makes one connector serve a whole team.
The remote server is also where the operational burden lives: uptime, monitoring, patching, and keeping the integration current as the underlying API changes. Whoever hosts the server owns that burden, whether that is your engineering team or a provider.
We compare the two models properly in remote vs local MCP servers, but the short version for team plans is that remote is not an option, it is the shape of the feature.
What does a good team rollout look like?
Start narrow: one connector, a small pilot group, and read-heavy scope. Let the pilot surface what people actually ask Claude to do, then widen access and add write actions deliberately. Admin enablement makes this easy to stage, because the admin decides when the wider workspace sees the connector at all.
The rollouts we have run for client teams follow the same shape. The pilot group authenticates, uses the connector in real work for a week or two, and the questions they ask become the roadmap. Write actions get added once the read experience has earned trust, with delete and outbound actions like send gated behind confirmation from day one.
The other rollout job is expectations: telling the team what the connector can and cannot do prevents both under-use and the disappointment of asking for actions that were deliberately left out of scope.
Where we fit
We build, host, and maintain custom connectors for client teams, so this rollout playbook is how our own deployments go live. If your team would rather own the server, the same staging still applies.