A support lead wants agents working Intercom from inside ChatGPT: read the conversation, check what the customer bought, draft the reply, send it. The same connection, left unscoped, can also delete a contact or push a message to a saved audience. Intercom MCP access for support team work is mostly a matter of three decisions. Which of those calls gets through, from which Intercom account, and into which inbox.
MCP (Model Context Protocol) is the standard way an AI assistant calls tools in other apps. That is how ChatGPT reaches a tool at all. Elaichi serves it at one endpoint, https://api.elaichi.ai/mcp, the same address for every organization. The URL does not decide what a client reaches. The OAuth grant behind its token does. A grant is the approval one person gave one named client on Elaichi's consent screen. Wiring the client up is covered in the ChatGPT setup walkthrough. This post is the work you do before the agents arrive.
What Intercom MCP access for support team comes down to
Three decisions: which Intercom tools the support role may call, whose Intercom account those calls run as, and which inbox a reply lands in. Nothing on the consent screen settles any of them. "Run your connected tools" runs every tier of connected tool, writes and deletes included. "Delete data and remove access" covers only Elaichi's own deletes. A member also needs the tool:execute permission in their role, which the built-in Member, Team Admin and People Admin roles hold.
The client's own settings do not settle them either. ChatGPT's plugin permission setting offers Always ask, Allow read actions, Allow low-risk actions and Allow all actions. That list comes from OpenAI's admin controls article, checked October 2026. It acts on the Elaichi app as a whole. Before a supported action runs, ChatGPT may show an approval card, depending on the app permission setting and the action's context. See OpenAI's guide to managing app permissions, checked October 2026. That prompt asks a person at the keyboard; it does not decide which Intercom tools exist. Codex sets approval per server and per tool, and runs into the same limit (OpenAI's Codex MCP documentation, checked October 2026). Elaichi never lists a connected tool by name in a client's tool list. A control that gates individual tool names therefore sees execute_tool, run_code and two Elaichi operations, never one connected app. Per-app and per-tool rules belong in Elaichi.
Is Intercom a catalog connector, or your own MCP server?
Check Intercom's connector page in the connector catalog before you plan anything else. Elaichi's catalog of 650+ connectors holds two kinds. Some Elaichi authors and runs itself. The rest are native MCP connectors: the vendor builds and runs its own MCP server, and Elaichi handles sign-in, access and audit in front of it.
If Intercom is not in the catalog, a team on Gold can bring Intercom's own remote MCP server in as the organization's connector. That takes the connector:create permission, which among the built-in roles only Org Owner and Org Admin hold. Tools are then discovered per connection, using that connection's own credential, because different members' accounts can see different tools. Each such connector has a new-tool policy. Auto makes a newly seen tool usable at once. Review holds it until someone who can manage the connector approves that exact definition. Review is the right setting for a support rollout. One more default matters here. A remote tool its server does not mark read-only or non-destructive counts as destructive. An unannotated server therefore arrives with everything tiered as a delete.
Putting another vendor's server behind your own address is a decision to make deliberately. OpenAI asks for extra due diligence on an aggregator, its word for a third-party MCP server that proxies another provider's service. See OpenAI's MCP servers guide, checked October 2026. The rest of this post is the answer for Elaichi: restrictions, a frozen inbox, and the audit log afterwards.
Allow reads and replies, or block deletion and broadcast?
Both shapes work. They fail differently.
An allow rule turns on the allowlist for its layer just by existing. Once the support role carries any allow rule, the allowlist decides everything. Every connector and tool none of its allow rules names is blocked for that role, across all connectors, not only Intercom. So an allowlist naming Intercom's conversation read and reply tools also needs whole-connector allow rules for every other app support touches. Those can be separate rules, because a layer's allow rules merge into one allowlist.
Blocks are the other shape. A layer with only block rules has no allowlist, so everything it does not name passes. Blocking the contact delete tool and the broadcast tool leaves every other Intercom tool reachable, including ones the vendor adds later.
Pick by how narrow the role is. Use an allowlist for a role whose whole job is one or two apps. Use blocks, plus the review new-tool policy, for a role that touches many. One further difference decides close calls. Allow rules match the operation Elaichi stored when the rule was saved. Block rules match by name or by operation, so renaming a tool cannot slip it past a block. Why blocks match tool names and allows do not has the mechanics.
Write the block rules for contact deletion and outbound broadcast
A restriction is a rule that says which connectors and tools a role or one member may reach. In Elaichi, restriction targets are role or user only; the organization default is the absence of a rule, which means allow everything. So a support team's rules go on the role its members hold, or on each person. Writing one needs the restriction:manage permission and the restrictions plan feature, which Gold and Black both include. A rule aimed at one member also needs restriction:override.
Copy the tool names from the connector's page in the console rather than typing them from memory. When a rule is saved, Elaichi looks each named connector and tool up in the organization's catalog. A name it cannot find is refused with a 400. Each tool's operation is stored beside the name. A rule may name connectors from any number of vendors. One rule can carry the Intercom entries and anything else the role should not reach.
Restriction changes reach every surface within about two minutes.
Tell the team what a block looks like from their side. A restricted tool is left out of what Elaichi advertises as runnable. It is not hidden, though. Search names it, flagged restricted, with no description or schema and no way to call it, alongside a count of restricted matches. Calling the name anyway returns a refusal. It says whether the block comes from their role or from their own account, and that an admin can lift it. The refusal does not name the rule, who wrote it, or what else it covers.
That lift is an access request. Any member can file one for themselves, and filing needs no permission. Only a person in the console resolves it, under Governance then Access requests, after confirming their identity. No AI client and no in-app agent can approve or deny one. Approving a connector or tool request records an access grant for that one requester. It writes no restriction rule, leaves the role's rules alone, and changes nobody else's access. Know the ending before you start granting. No API route or console screen lists grants or revokes one. A grant ends when it expires, when a later approval supersedes it, or when the member is removed from the organization. An approval made in the console carries no end date.
Pin the inbox with a frozen parameter
Frozen parameters, labeled Locked-in values in the console, are argument values written into a toolbox entry that a caller cannot override. A toolbox is a named list of tool entries, each pinned to one connected account. Freeze the inbox or team argument on the reply entry, and every call that runs through that entry lands in that inbox. The frozen key must name a real argument of the tool; an unknown key is refused with a 400 that lists the valid arguments. The argument named connection cannot be frozen, because it is how a caller picks which connected account a tool runs against.
The model can tell a value is set. Elaichi prefixes the advertised description with a note such as (frozen: team_id=support). Short scalars show, and longer strings show as an ellipsis. Anyone who can open the toolbox reads every frozen value in full. What the client cannot do is change one. At execution, frozen values are merged over the caller's arguments, so passing the key as an argument cannot move the reply.
The catch is reach rather than the freeze. A freeze holds only on calls that run through the entry carrying it. Anyone who can use the Intercom connection themselves has the same tool without the freeze, through their All tools toolbox. So for the pin to bind, the connection's owner keeps the connection unshared. They pin it into the entry with the frozen value. Then they share the toolbox at use, not the connection. Do not try to close the unfrozen path with a restriction. A restriction matches the catalog tool, so it would block the frozen entry too. Locking an agent's tool arguments walks the same mechanics through a payment field.
Whose Intercom account sends the reply
A toolbox shared at use runs every grantee's call on the connection pinned in the entry, under the authority of whoever pinned it. One shared Intercom connection therefore means every reply posts from that one Intercom account. That account's own permissions in Intercom apply to everybody using the toolbox.
The other shape is per person. Build a template, share it at use, and each agent stamps their own copy and picks their own Intercom connection for each entry. Elaichi fills nothing in by itself; the person stamping chooses a connection per app, or skips it and adds one later. Each agent's calls then run on their own Intercom sign-in, with their own permissions there. The trade-off comes back. A person who can use their own connection also reaches the unfrozen tool, so the inbox pin becomes guidance rather than a wall.
Whoever pins a connection is recorded as that entry's delegator and must hold use on it. If they stop being an active member, or lose use, the entry stops resolving for everyone, the toolbox owner included. Pin with an account held by someone who will stay. When it does break, a person with edit on the toolbox and use on the connection re-pins it; nothing re-pins by itself.
What the audit log shows afterwards
The audit log is Elaichi's own record of what ran. Every connected-tool call that reaches execution writes one row. It records the person, the toolbox, the tool's advertised and catalog names, the connector, and the connection the call actually reached. It also records the tool's classification, how approval was given, the surface, and the MCP client's id when the call came from one. The row ends with the outcome and what the call touched. For a list or a search it records the resource type and how many items came back, nothing about the items. The console renders each row as a sentence that opens with where the call ran, so a ChatGPT call reads as a ChatGPT call.
Two details save an argument later. Connected-tool calls sit in the audit log's assistant category, not under MCP; the MCP category holds client grant events. And a call refused at the scope check writes no row at all, because that refusal happens before any executor runs. Elaichi keeps 90 days of audit history. For a longer trail, forward it to your own log service: export to your own Datadog comes with the Black plan, which is launching soon.
When an agent leaves, removing them revokes the MCP client grants they hold, and their client fails on its next call. Entries they pinned resolve as unmet until someone re-pins them.
When this is more than you need
Suppose support is the only team using an assistant, and one Intercom account is already shared across the whole desk. There is little here for a second vendor to add. The same holds if Intercom's own MCP server meets your requirements and Intercom is the only app in the picture. One vendor is simpler than two. Elaichi earns its place when the same people need several apps at one address, under one set of rules, with one audit log. It earns it again when a leaver has to lose everything at once. When you don't need an MCP gateway yet is the longer version of that answer.
For the layer above this playbook, read who may do what, in which app. For the same exercise on a different desk, see Zendesk for support agents, minus bulk deletes, or browse governance use cases.
