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

> One custom connector, added once by an Owner, and every teammate reaches the apps they already have access to — inside their own permissions, not the connector's.

**TL;DR** Claude makes one connection, to Elaichi. Your apps are connected inside Elaichi, so adding Salesforce later does not mean touching Claude again. On Team and Enterprise an Owner adds the connector once; everyone else enables it and signs in as themselves, which is what keeps each person's access their own.

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

| Symptom | Usually |
|---|---|
| No tools appear after connecting | No applications connected in Elaichi yet, or no toolbox you can reach. Connect one first |
| **Add custom connector** is missing | Team or Enterprise, where only an Owner can add one. Ask them, then enable it for yourself |
| A tool you expect is missing | A restriction blocks it, it is not in a toolbox you can reach, or the 30-tool threshold collapsed the list — ask Claude to search for it |
| A call is refused after consent | The scope it needed was not granted. Reconnect and widen the consent |
| A newly connected app does not show up | The tool list is cached. Start a new conversation, or reconnect the connector |

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](/connectors/) and start with whichever system your team lives in.

## FAQ

### Who in my organization can add the Elaichi connector to Claude?

On Team and Enterprise plans, only an Owner can add a custom connector. That is a Claude-side rule, not an Elaichi one. Everyone else enables the connector for themselves once it exists and signs in as themselves — which is the behaviour you want, because each person's tools then follow their own access rather than the Owner's.

### Does connecting Claude to Elaichi work on a Free plan?

Custom connectors work on Free, Pro, Max, Team and Enterprise. Free is limited to one custom connector, which is usually not a problem here: Elaichi is one connector no matter how many applications sit behind it, so a single slot covers your whole stack.

### Why does Claude need a publicly reachable endpoint?

Claude connects from Anthropic's cloud rather than from your computer, so the endpoint has to be reachable on the public internet. A localhost address will not work, and neither will a server that is only reachable inside your VPN. The hosted Elaichi endpoint is the one to paste.

### I added a new app in Elaichi and Claude cannot see it. What happened?

Almost always a cached tool list. Most MCP clients cache what they were told at connection time, so start a new conversation or reconnect the connector. If it still does not appear, check that the app is in a toolbox you can reach and that no restriction blocks it for your role — a blocked tool is never advertised in the first place.