Connect your company's apps to Claude, without giving Claude the company

Someone on your team connects Notion to Claude. Then someone else connects Jira. Then a third person connects the CRM, using their own credentials, because that was the only way to make it work. Six weeks later nobody can answer a simple question: which applications can Claude reach, on whose behalf, and what happens when one of these people leaves.

The fix is not to ban it. It is to make the governed path the easy one — a single connector, added once, that everyone signs into as themselves.

Claude makes one connection, not many

This is the part worth understanding before you touch any settings, because everything else follows from it.

Claude connects to one thing: Elaichi. Your applications are connected inside Elaichi, not inside Claude. Nobody adds Slack or Jira or HubSpot to Claude directly — they arrive through the endpoint you set up once.

That indirection is the whole point. Because every call travels through Elaichi rather than around it:

• Access follows the person. Toolboxes, team shares and per-person restrictions all still apply when the caller is Claude.
• Blocked tools are never offered. A tool your organization has restricted is not advertised to Claude at all, so the model cannot be talked into calling it.
• The call is attributed. Tool calls land in an append-only log alongside every other action, including the identifier of the record they changed.
• Revoking is one action. Disconnect an app in Elaichi and it is gone from Claude too, with no hunting through anyone's client settings.

Connect apps directly in Claude instead and you lose all four at once.

Who adds it, and what everyone else does next

This is where Claude differs most from the other clients, and it is worth planning for rather than discovering.

On Team and Enterprise, only an Owner can add a custom connector. That is Claude's rule. It sounds like friction and is actually the useful shape: one person does the setup once, and everyone else enables the connector for themselves and signs in with their own Elaichi account. Each person's tool list is then resolved against their own access — the Owner's setup does not hand the Owner's reach to anyone.

On Free, Pro and Max anyone adds it themselves. Free allows one custom connector, which is rarely a constraint here, because Elaichi is one connector however many applications sit behind it. Your whole stack fits the single slot.

So the rollout is: an Owner adds it once, you tell everyone else to enable it, and each person signs in. There is no per-person provisioning step and no list of who has which app.

Adding the connector

In the Elaichi web app, open Connect your AI client and copy the endpoint.

In Claude, open Settings → Connectors, choose Add custom connector, and paste it. Under Advanced settings, leave OAuth Client ID and Client Secret empty — the endpoint registers clients automatically, so there is nothing to generate and nothing to store.

One constraint to know in advance: Claude reaches the endpoint from Anthropic's cloud, not from the machine you are sitting at. A localhost address will not work, and neither will anything only reachable from inside your network.

The consent screen is the security boundary

Signing in brings up a consent screen, and it deserves more attention than most OAuth screens get.

Inside the Elaichi web app, a write is confirmed in the moment: you are asked, you agree, the action runs. Over MCP there is no trusted place to ask — the model on the other end could claim its own approval and you would have no way to tell. So the approval moves forward to this screen, and the scopes you grant here are the standing approval.

Four scopes, and only Read is granted by default:

• Read — everything you can already see: people, teams, tools, connections, settings, and admin records like the audit log. Never secret values.
• Create and change — create and modify teams, roles, tool sets, connections and organization settings.
• Delete — permanently remove them, and this reaches inside your connected applications too. It cannot be undone.
• Run tools — run tools from the toolboxes you choose on this screen.

For ordinary use you want Read and Run tools. That is enough to work in your connected applications without letting the model reshape the organization. Widening later means re-consenting, which is a feature rather than an obstacle.

Open the Details link behind Read at least once. It covers more than the word suggests, including SSO connections, directory group mappings, verified domains, pending invitations and API token metadata.

What Claude actually sees

Your access, not the organization's. The endpoint is scoped to the account that signed in — the same boundary as the web app. Two people who paste the identical URL do not get the identical tools, because the tool list is resolved per request against the person behind it.

There is one behaviour that surprises everyone. Past 30 advertised tools — counting Elaichi's own catalog operations together with your connected ones — individual tool names are replaced by two meta-tools, search_tools and execute_tool. Elaichi's own catalog nearly reaches 30 on its own, so a single connected application usually trips it. This is automatic and not a setting.

When it happens, Claude finds tools by searching rather than browsing, and that search ranks lexically, not semantically. "create deal" and "list issues" retrieve well; "help me understand our pipeline situation" does not. Worth telling your team once, because it changes how they phrase things.

If something does not work

To disconnect, remove the connector in Claude, or revoke the grant in Elaichi — revoking stops the token working immediately, which is the one to use when somebody leaves.

Once it is connected, the interesting question stops being "how do I wire this up" and becomes "which tools should each team actually have". That is what the per-application guides are for: browse the connector catalog and start with whichever system your team lives in.