You can connect Intercom to Claude using the Model Context Protocol (MCP), and once it’s connected, Claude can pull up a customer’s conversation history, draft a reply grounded in your help content, or find every open ticket about a specific bug — without you switching into the Intercom inbox to look it up. This guide covers what Intercom’s MCP server does, both ways to connect it — directly or through a gateway — and one thing worth knowing before you try: Intercom’s OAuth isn’t currently open to every client that asks.

What the Intercom MCP server actually does

Intercom publishes a remote MCP server at mcp.intercom.com. It exposes conversations, contacts, and help content as tools Claude can call directly, so prompts like these work against your live workspace:

  • “What’s the conversation history with this customer?”
  • “Find every open conversation mentioning the export bug.”
  • “Draft a reply to this ticket using our billing help article.”
  • “Which contacts have an unresolved conversation older than three days?”

Claude reads and, depending on the tools you allow, writes through the same permissions your Intercom account already has — it isn’t a read-only export, it’s your actual support inbox and contact list, queried and drafted against on demand.

The catch: Intercom’s OAuth isn’t open to every client yet

Some servers in gate’s directory — Notion, Todoist, Airtable — let any AI client register itself and go straight through a one-click OAuth consent screen. Intercom’s MCP endpoint is one of a handful where that isn’t the case today: the vendor’s OAuth currently only admits clients Intercom has allow-listed in advance, rather than opening registration to any client that shows up. In practice, that can mean a connection attempt from a new or less-common client fails at the authorization step, even though the server itself is real and documented.

This is the same gap covered in MCP OAuth scopes explained: a server supporting OAuth in principle isn’t the same claim as every client being able to walk through it today. If you hit an “unauthorized client” error connecting Intercom, that’s the most likely reason — not a mistake in your setup. See the unauthorized client error explained for the general pattern and workarounds. Whether a given client can connect changes as vendors expand their allow-list over time, so it’s worth checking again later if it doesn’t work on your first attempt.

Option 1: Connect Intercom to Claude directly

If the client you’re using is one Intercom currently admits, the setup is:

  • Open Claude’s connector or MCP settings.
  • Add a remote server pointing at Intercom’s MCP endpoint.
  • Sign in with your Intercom account when prompted — standard OAuth, so Claude never sees your Intercom password, and you can revoke access from Intercom’s own settings at any time.

That’s enough if Claude is the only AI client you use with Intercom. The tradeoff shows up once you add a second client — ChatGPT for a quick lookup, Cursor for pulling a customer’s history into a bug fix — or a second person on the support team: each one needs its own attempt at the same OAuth step, with the same chance of hitting the allow-list wall independently.

Option 2: Connect it once, through a gateway

If you’re already juggling more than one MCP server or more than one AI client, wiring each pair directly gets old fast — that’s the connection sprawl covered in what an MCP gateway is. The idea is to connect Intercom (and everything else) to one gateway URL, then point every AI client at that single URL instead of reconfiguring each one and re-running the OAuth step per client.

With gate specifically, connecting Intercom looks like this: add gate’s gateway URL to Claude once, then pick Intercom from the Intercom server page in the directory and sign in the same way you would directly. gate’s catalog tracks each server’s currently verified connectivity — including cases like this one, where a vendor’s OAuth is still allow-listed — so you know what to expect before you start, instead of finding out mid-flow. See the full list of servers on the MCP servers page.

What to check before you connect a support inbox

An Intercom workspace usually holds more than the one conversation you had in mind when you connect it — every customer’s message history, every internal note, every macro. A few things worth checking before or right after you connect:

  • Can it reply, or only read? A tool that surfaces conversation history is low-risk. A tool that can send a reply is a different category — a message sent to a real customer under your team’s name isn’t something you can quietly take back once they’ve read it. Know which tools are enabled before handing Claude a prompt like “close out this ticket.”
  • Does it see internal notes and private data? Support conversations often carry account details, refund history, and internal-only notes alongside the customer- facing thread. Know what’s in scope before you ask Claude to summarize “everything about this account.”
  • Could a customer’s own message steer the reply? A conversation thread is exactly the kind of untrusted content covered in the confused deputy problem in MCP: if Claude reads a customer message and then acts on instructions buried in it, the tool call is still authorized — it’s just doing something you didn’t intend.
  • Who else on the team connects it? If more than one teammate wires up Intercom to their own client, a shared, revocable setup beats everyone holding their own reply-capable grant — the same question covered in MCP access control for teams.

You can run a quick, no-signup check on any server’s tool list with gate’s free MCP security scanner, which looks for prompt injection and hidden instructions in tool descriptions before you rely on a server day to day.

Troubleshooting the connection

  • “Unauthorized client” or the OAuth screen never appears. Most likely the allow-list issue above — the client you’re using may not be one Intercom currently admits for this endpoint.
  • Sign-in succeeds but Claude can’t see a conversation you know exists. Intercom’s tools respect your user’s own permissions in the workspace; a conversation assigned to a team you’re not part of won’t show up any more than it would in the Intercom inbox itself.
  • Tools disappear after an Intercom update. Remote servers can change their tool list without warning. If you’re connected through a gateway, that kind of change is exactly what drift detection is meant to catch — see how MCP rug pulls work for why a one-time review isn’t enough.
Where gate fits: gate’s directory lists each server’s currently verified connectivity — one-click OAuth, key-based, or allow-listed like Intercom — so you know what kind of setup to expect before you start. Every server is scanned for prompt injection before it goes live, and every call goes into a plain-language log, which matters more for a tool that can reply to a real customer than for most. See the full gateway at /mcp-gateway.

The bottom line

Connecting Intercom to Claude with MCP is a normal OAuth flow when the client you’re using is one Intercom currently allows — direct if it’s your only client, or once through a gateway if you want the same conversation and contact access shared across every AI client the support team uses. If the connection fails at the authorization step, that’s worth reading as “not allow-listed yet” rather than a broken setup. Either way, know which tools can only read a conversation and which can send a reply — that distinction matters more here than on most other servers in this series.