Claude and ChatGPT connectors for teams

Claude and ChatGPT connectors for teams, and where they stop

Start by giving the built-in option its due. If two people need an assistant to read a document store, the connectors already in the client will do it today, for nothing, with no procurement. Anything this post says about limits should be read against that baseline, because most teams should start there.

The limits are not defects. They are the boundary of what a connector configured by one person can cover, and both of the ones that matter are documented by the vendors themselves.

Limit one: the connection belongs to a person

OpenAI's help center describes connected apps in ChatGPT as something you connect by signing in to the account that already has access to the information you want to use, with availability depending on your plan, region, workspace, role and interface. It notes that some apps instead use an administrator-managed connection.

Anthropic's equivalent, on custom connectors using remote MCP updated 11 August 2026, is similar in shape: a person adds a connector and authorizes it.

Read those as an access model rather than a setup guide and the consequence is clear. Access follows individuals. That is exactly right when the thing being reached is that individual's own account, and it is the wrong unit when the question is which of the company's two workspaces a given team may write to.

Limit two: the call comes from the vendor's cloud

This is the one that surprises people mid-project, and it is worth quoting because it invalidates a common plan.

Anthropic's documentation states that when you add a custom connector, Claude connects to your remote server from Anthropic's cloud infrastructure rather than from your local device, and that this is true across every Claude client including the desktop app. A server hosted on a private corporate network, behind a VPN, or blocked by a firewall will not connect even though you can reach it from your own machine. Making it work means allowlisting the published IP ranges in your firewall.

So "we will just point it at the internal one" is not a plan unless somebody in network security has agreed to open a path. Worth discovering in week one rather than week six.

What actually breaks at company scale

Three questions arrive in the same order at every company, and none of them is about capability.

Who may reach what. With per-person connectors the answer is assembled by asking people, because no single place already knows. That is tolerable at five people and not at fifty.

How access is taken away. When somebody leaves, each connector they authorized is its own small task, in a place their manager may not have an account. The work scales with people multiplied by systems.

What happened. After an unexpected change, the useful record names which account was reached, not just that an assistant did something. Per-person connectors produce per-person histories, which is a different artifact from an organization's audit trail.

The version of this that keeps the native experience

Worth being clear that a control plane is not an alternative user experience. It is reached through the same connector mechanism the clients already have, so people keep using Claude, ChatGPT or Cursor exactly as before. What changes is what sits on the other end of the connection.

With Elaichi that is one organization-wide endpoint. Everyone points at the same address and signs in, and the grant decides what they see. There are no per-toolbox URLs and no embedded tokens, and no server to mint per person.

The three questions above then have single answers. Restrictions say which connectors and which individual tools a role or a user may reach. Removing or suspending a member revokes every live grant in the same transaction as the membership change, and the grant is re-read on every call with no cache. The audit trail records one entry per tool-call attempt, succeeded or failed, naming the connection actually reached rather than the one intended, with argument names but never argument values.

Role and restriction changes are the slower path at about two minutes, through a short cache plus edge propagation. It is worth knowing which changes are fast and which are not.

The honest case for staying native

Do not buy a control plane to find out whether agents are useful. Find that out with the connectors you already have, because the answer arrives in a week and costs nothing.

Stay native if the people involved are few, if the accounts they connect are genuinely their own, and if nobody outside the team is asking what the agents touched. That describes a lot of teams, and for them the built-in connectors are not a compromise but the correct tool.

There is also a middle path worth naming: some systems governed centrally, the rest left to individuals. Nothing forces an all-or-nothing decision, and the systems that belong in the middle are usually the ones with shared accounts or customer data in them.

What to check before you decide

Pick the one system you would least like an agent to write to by mistake. Ask who currently has it connected, how you would find out, and how you would disconnect it for one person by tomorrow morning.

If you can answer all three from memory, the native connectors are serving you. If you cannot, the gap is not a missing feature in Claude or ChatGPT. It is that you are asking an organization-level question of a per-person tool. The MCP gateway comparison covers what to weigh next.