How do you connect Elaichi to ChatGPT?
To connect Elaichi to ChatGPT, a workspace admin creates one custom app from Elaichi's MCP endpoint and publishes it, and each person signs in to it with OAuth. There is no API key to paste, no per-user URL and no server to run. The rest of this guide covers the plan you need, the clicks, what people see, and the rules that decide what ChatGPT can do.
Your support team already lives in ChatGPT. Someone asks for Zendesk inside it, and the shortest path is a personal API token pasted into a custom setup. Do that ten times and you have ten credentials nobody can revoke centrally. One endpoint behind OAuth replaces all ten.
MCP (Model Context Protocol) is the standard way an AI assistant calls tools in other apps, and its specification is public. Elaichi serves every connected SaaS account through one organization-wide endpoint, POST /mcp: standard MCP over Streamable HTTP, behind OAuth.
Which ChatGPT plans can use a custom MCP app?
Business, Enterprise and Edu, with write actions; Pro, for reads only. OpenAI's help center says full MCP support, write actions included, is rolling out in beta to Business, Enterprise and Edu, and that Pro users can connect MCP servers with read and fetch permissions in developer mode (OpenAI help center, checked October 2026).
It is a beta, and the same page warns that "Functionality, UI, and permissions may change". The menu paths below are as of October 2026. If a label has moved, the value you enter has not.
How does an admin add the Elaichi endpoint?
As one app, created once and published to the workspace. On Business, OpenAI's page says "Only Admins can use developer mode". Enterprise and Edu admins can grant it to chosen members through role-based access control.
- Open Workspace settings, then Apps, then Create.
- Enter your organization's Elaichi MCP endpoint, and choose OAuth as the authentication.
- Click Scan Tools, then complete the OAuth prompt so the scan can finish.
- Click Create. The app is saved as a draft in Workspace settings.
- Publish it. Published apps appear "in users' Apps settings in ChatGPT with the label custom".
One detail costs people a second attempt. OpenAI's page says that "For Business plans, apps cannot be updated after publishing at launch." Check the name and settings before you press Publish.
The address is the same for every member. There is no MCP server to create, list or revoke per person, and nothing about the URL is a secret. What varies is the grant behind each person's sign-in.
The same address works for Claude and Cursor. An admin adds it once where each client allows, and each member connects it there. Claude and ChatGPT connectors vs one MCP endpoint compares that model with each client's own connectors.
What does a person see the first time they sign in?
A sign-in screen, then a short list of tools. ChatGPT opens Elaichi's OAuth flow, the person authenticates, and ChatGPT holds a grant scoped to that person. OAuth 2.0 is the standard behind that handshake: the client receives a grant, never the password.
How people authenticate depends on what the organization set up. Elaichi supports Google, GitHub and Microsoft sign-in, email codes, TOTP multi-factor codes with recovery codes, and passkeys. Enterprise SAML and OIDC single sign-on are built in, with SCIM v2 provisioning and group-to-role mapping beside them.
What appears after sign-in is narrower than most people expect, by design. A member sees only what they own or what was explicitly shared with them. No org-level permission silently widens that list, org owners and admins included.
If the person's role lacks the tool:execute permission, the list comes back empty and any call returns an error naming the missing permission. Guest, Auditor and Billing Admin are the roles without it. That is the right outcome for a compliance reviewer who signs in out of curiosity.
Where do the app accounts come from?
The person connects them, inside ChatGPT or in the Elaichi console, from a catalog of 500+ connectors. Elaichi authors and serves those connectors from its own infrastructure, so your team runs no MCP server per app.
The connect step returns a one-time connect URL that carries no token, which is why it is safe to hand back through ChatGPT. Credentials never live in Elaichi itself. A separate credential service holds each account's secrets, encrypted at rest, and owns token refresh. A failed refresh marks the connection needs_reauth, so it shows up as a connection to fix rather than a silent failure.
An organization can bring its own OAuth app per connector. That right is gated on connector:manage, not connection:manage, so everyone who can delete a connection does not also gain the power to repoint the organization's OAuth app. When the catalog lacks an app, custom connectors are authored from JSON config.
Why does ChatGPT show only search_tools and execute_tool?
Because in Elaichi, connected tools are never listed one by one, however few there are. ChatGPT looks a tool up with search_tools and calls it with execute_tool, so those two in the tool list are the expected view, not a broken connection.
A tool withheld by a restriction never appears in search results, because it was handed to nobody. execute_tool is only a naming indirection: it unwraps to the same tool name and arguments and passes the same checks. Search is lexical, with a floor that keeps a query about one app from returning a tool from another, as how MCP tool search picks one tool from hundreds explains.
What decides which tools a person's ChatGPT can call?
Three layers, checked against the same resolver on every call. Keep them apart, because they fail differently.
- Roles. Around 38 permissions are grouped into roles, with exactly one role per member.
tool:executegates the whole endpoint. - Sharing. A grant of view, use or edit on a connection or toolbox makes it visible to somebody who does not own it.
- Restrictions. These decide which connectors and which individual tools a target may reach. In Elaichi, restriction targets are role or user only; the organization default is the absence of a rule, which means allow everything. A rule on a user replaces the role rules for that user rather than adding to them.
Two details catch people. First, the allowlist stage engages on the presence of an allow rule, not its contents, so an allow rule that names nothing denies everything. Second, a block matches a tool's name or its operation, while an allow matches the operation only. Why blocks match tool names but allows don't explains the asymmetry.
Frozen parameters sit underneath. A frozen argument is removed from the schema ChatGPT is shown, and its value is merged over whatever the model sends, so the model cannot change it. One condition: a freeze binds only calls made through its toolbox entry, so share the toolbox with the people it governs, not the connection itself. A role or restriction change takes about two minutes to apply.
Will ChatGPT ask before it writes something?
Sometimes, and you should not rely on it alone. OpenAI's page says ChatGPT may ask for confirmation before a write or modify action, depending on the app's permissions and the action's context.
The guarantee lives on Elaichi's side. A tool a restriction withholds cannot be called at all, however the prompt is phrased. OAuth scopes add a ceiling: reads need mcp:read, writes mcp:write, and deletes mcp:destructive. A tool classified forbidden is reachable under no scope.
How do you check what ChatGPT did?
In the audit trail. Elaichi writes one entry per tool-call attempt, succeeded or failed, naming the account the call actually reached, and the OAuth client it came through, with ChatGPT marked verified. The call is recorded under the person who signed in. What an AI agent audit log must capture covers the fields in full.
A read-only Auditor seat is free, so a reviewer can read the trail without consuming a license. Beyond the in-app trail, export to your own Datadog comes with the Black plan, which is launching soon.
What happens to ChatGPT access when somebody leaves?
It ends on the next call. In Elaichi, removing or suspending a member revokes every live grant in the same transaction as the membership change, so the next request from that person's ChatGPT session fails. Suspension works the same way.
The removal runs a check first. A personal connection still referenced by a toolbox has to be transferred to the organization, a team or another member, or deleted, before the removal goes through. Offboarding AI access, contractors included walks through the order.
What does this setup not protect against?
Prompt injection on the endpoint. The prompt-injection write gate lives in the Elaichi agent window and does not apply to a raw tool call. By the time a call reaches the endpoint, the model has already decided what to call.
So do not present this internally as an anti-injection control. What it does give you is containment: a manipulated model still cannot call a tool its user was never granted, and whatever it did call is attributable afterwards. Enforcement runs at four points against the same resolver: browse, connect, advertise and execute, plus a final check on the fully substituted outbound URL.
When should you not connect ChatGPT to Elaichi yet?
When four people use ChatGPT against two apps they each own personally. That is more machinery than the problem deserves. Turn up the apps' own admin controls, and revisit when the first contractor leaves or a team asks for an account that is not theirs. When you don't need an MCP gateway yet lists the signals.
Cost is the other honest constraint. Gold lists at $15 per user per month in USD, and the pricing page shows the price for your region. Gold starts with a 14-day trial, no credit card to start. Checkout does collect a card, and it sets the paid trial to the remaining days rather than granting a fresh 14, so it is one continuous trial rather than two.
If the sign-in fails, the OAuth error guide says which step broke, and if a tool you expect is missing, the missing-tools checklist walks the checks in order. When you are ready, choose which connectors to turn on and which team goes first. Browse the connector catalog or the team pages, and for one team's rollout, read each rep's own Salesforce access, in ChatGPT.
