Connect your company's apps to ChatGPT: the plan gates, and what to do about them

Most guides to connecting ChatGPT to something start with the steps. For ChatGPT the steps are the easy part — three clicks, genuinely. What derails a rollout is discovering, two days after promising it to a team, that half of them are on a plan where the feature does not exist and the other half need an admin to flip something they cannot see.

So this starts with the gates.

Two gates, both on ChatGPT's side

The plan. MCP support requires Business, Enterprise or Edu, and it is web-only today. Someone on Plus has no path at all. Someone on Business using the desktop app has a path, but not from the desktop app. Neither of these is something Elaichi can change; they are properties of ChatGPT.

Developer mode. It has to be on for the account, and it lives under Advanced Settings. On Business plans only admins and owners can turn it on. On Enterprise and Edu an admin can also grant it through Permissions & Roles → Connected Data.

Check both before you announce anything. The failure mode when you skip this is not an error message — it is a sign-in that loops or simply never returns, which people read as "the integration is broken" rather than "my account is not eligible".

You are connecting one thing, not your whole stack

Once you are through the gates, the shape is worth understanding, because it is what makes the rest low-maintenance.

ChatGPT makes a single connection, to Elaichi. Your applications are connected inside Elaichi, not inside ChatGPT. Nobody adds Salesforce or Zendesk or Google Drive to ChatGPT directly — they arrive through the one endpoint.

Because every call travels through Elaichi:

• Access follows the person, not the connection. Shares, team membership and per-person restrictions all still apply.
• A restricted tool is never advertised, so it cannot be invoked by a persuasive prompt.
• Every call is attributed in an append-only log, including the identifier of the record it touched.
• Disconnecting is one action in Elaichi, rather than an audit of who configured what in their own account.

Add an application in Elaichi next month and it appears in ChatGPT with nothing to reconfigure. The reverse holds too.

The three steps

Copy your endpoint first: it is behind Connect your AI client in the Elaichi web app.

1. In ChatGPT, open Settings → Apps and turn on developer mode.
2. Choose Create, paste the endpoint, then run Scan tools.
3. Sign in to Elaichi and approve what the app can do.

It is an OAuth endpoint, so there is no bridge command to configure, no API key to paste, and no credential anywhere in the URL. You will not be asked for a client ID or secret either — the endpoint registers ChatGPT automatically on first contact.

ChatGPT cannot reach a local MCP server, so the hosted endpoint is the only option here.

The consent screen, and the prompt that is not the boundary

Signing in brings up a consent screen. In the Elaichi web app, a write gets confirmed as it happens — you see the request, you agree to it. MCP has nowhere trustworthy to put that question: whatever is at the other end could simply report that you said yes. The approval therefore has to happen up front, which makes the scopes on this screen the whole of your consent.

Four scopes, and only Read is on by default:

• Read — everything you can already see, including admin records like the audit log. Never secret values.
• Create and change — teams, roles, tool sets, connections, organization settings.
• Delete — permanent, reaches inside connected applications, cannot be undone.
• Run tools — run tools from the toolboxes you pick on that screen.

Read and Run tools is the combination most people want.

Now the ChatGPT-specific nuance, and it is the one worth repeating to your team: ChatGPT prompts for confirmation on write actions, based on your permissions. That prompt is a convenience. It is not the security boundary. The boundary is the scopes you granted and the restrictions your organization set — both of which hold whether or not anyone reads the prompt. Teams that treat the in-chat confirmation as the control end up granting broad scopes and relying on attention, which is exactly backwards.

What each person sees

Their own access, not the organization's. Whoever signed in is the boundary, exactly as it is in the web app — so two colleagues pointing ChatGPT at a URL character-for-character the same do not end up with the same tools.

One behaviour catches people out. Past 30 advertised tools — Elaichi's own catalog operations plus your connected ones — individual names are replaced by search_tools and execute_tool. The catalog alone nearly reaches 30, so one connected application usually trips it. It is automatic, not a setting.

After that ChatGPT finds tools by searching, and the search ranks lexically, not semantically. Concrete tool-ish phrasing wins: "create invoice", "list open tickets". A full sentence about what you are trying to achieve ranks badly.

When the sign-in will not complete

To disconnect, remove the app in ChatGPT, or revoke the grant in Elaichi. Revoking stops the token working immediately, which is what you want during an offboarding rather than relying on someone to tidy their own settings.

With the gates cleared and the endpoint in place, the useful next question is which tools each team should actually be given. Start from the connector catalog and the guide for whichever system your team spends its day in.