Intercom's MCP server: two regions and a registration endpoint that says no

"Intercom connector" is the search that brings more people to this site than any other product query. We have had Intercom in our connector marketplace since July. On 14 September I reread Intercom's MCP docs and found that the note we show next to the connector was wrong. So before writing this I went back to Intercom's live endpoints and checked every claim again. Everything below was measured on 16 September 2026.

There are two hosts, and discovery won't tell you which one is yours

When I added Intercom in July, its docs described a US-hosted server. I wrote "US-hosted workspaces only" into our connector note. Intercom has since published a second region:

• US: https://mcp.intercom.com/mcp
• EU: https://mcp.eu.intercom.com/mcp

AU-hosted workspaces are still unsupported according to Intercom's MCP guide. I tried the obvious guess anyway. mcp.au.intercom.com does not resolve in DNS.

Each region is its own OAuth issuer. The authorization server metadata on the two hosts is identical apart from the hostname:

{
  "issuer": "https://mcp.eu.intercom.com",
  "authorization_endpoint": "https://mcp.eu.intercom.com/authorize",
  "token_endpoint": "https://mcp.eu.intercom.com/token",
  "registration_endpoint": "https://mcp.eu.intercom.com/register",
  "token_endpoint_auth_methods_supported": ["client_secret_basic", "client_secret_post", "none"],
  "code_challenge_methods_supported": ["S256"]
}

The part that bites is the unauthenticated response. Both hosts return the exact same 401 with the exact same body. A client probing either URL learns that it needs a token and nothing about where the workspace lives. The region is something the person connecting has to know, and most people do not know which region their Intercom workspace was created in. We hit the same shape of problem with other marketplace servers: the discovery documents look healthy and still don't carry the one fact you need.

Our note still says US only as I write this. Fixing it properly means changing the URL live connections use, so it goes through a real connection test first instead of riding along in a blog post.

The deprecated endpoint answers exactly like the new one

Intercom lists /sse as legacy and /mcp (Streamable HTTP) as the recommended transport. I sent the same initialize POST to both:

POST https://mcp.intercom.com/sse

HTTP/2 401
content-type: application/json
www-authenticate: Bearer realm="OAuth", error="invalid_token", error_description="Missing or invalid access token"

{"error":"invalid_token","error_description":"Missing or invalid access token"}

Byte for byte, that is also what /mcp returns. A connection check that stops at "the server answered 401, OAuth is required" passes for both. Our own end-user catalog points at /sse, and no check we run has ever flagged it. If you are copying an Intercom URL from an older tutorial or config file, check the path.

Discovery uses the older pattern

Look at that www-authenticate header again. There is no resource_metadata parameter. The 2025-06-18 MCP authorization spec expects the 401 to point at a protected resource metadata document, and the client to find the authorization server from there. Intercom publishes no such document:

GET https://mcp.intercom.com/.well-known/oauth-protected-resource      404
GET https://mcp.intercom.com/.well-known/oauth-protected-resource/mcp  404
GET https://mcp.intercom.com/.well-known/oauth-authorization-server    200

The only thing that works is the earlier convention: treat the MCP server's origin as the authorization server and fetch its metadata directly. A client that implements only the newer flow concludes that Intercom doesn't support OAuth. Ours did, back in July. The fix was a fallback at the end of our discovery path:

if (!authServer) {
  try {
    authServer = await discoverAuthServer(new URL(mcpUrl).origin);
  } catch {
    /* ignore */
  }
}

If you are writing your own MCP client and Intercom shows up as "no auth required" or "OAuth not detected", this is almost certainly why.

The registration endpoint says no

The metadata above looks like an invitation. There is a registration_endpoint, PKCE with S256, and none as an accepted token auth method, which is what a public client registered on the fly would use. Every signal says one-click connect should work.

It doesn't. On 10 September we sent a real registration with our production callback URL and got HTTP 400 invalid_redirect_uri. The error message says the redirect URI is not in the allowlist and to contact Intercom customer support. Intercom accepts dynamic registration only for redirect URIs it has already approved, which makes it dynamic in name only for anyone new.

That leaves two ways in that actually work today:

• Create an app in the Intercom developer hub, set its redirect URI to your callback, and use its Client ID and Secret in the OAuth flow.
• For a team tool that only ever touches your own workspace, send an Intercom access token as Authorization: Bearer .... Intercom documents this as a supported method.

The token route is fine for internal use. It is the wrong choice for anything your customers connect, because every call then runs with one workspace's full permissions instead of the person who approved it.

What you get once connected

Intercom's server exposes 14 tools. Two are generic, search and fetch, shaped for clients that want a single retrieval interface. The other 12 map to the API directly: conversations, contacts, companies and help center articles. Only three of them write:

• add_internal_note needs the Write conversations permission.
• create_article and update_article need Read and write articles.

That split matters if you put Intercom behind an assistant other people talk to. An assistant that can search conversations and read contacts is a support tool. One that can rewrite your public help center is a different risk, and it is worth deciding up front whether the app you register should ask for article write access at all. There is more on that trade-off in designing AI actions for trust.

Before you connect Intercom

Use the /mcp path, and plan for an Intercom app with a Client ID and Secret, because self-registration will be refused. If your MCP client then reports that Intercom needs no authentication, check whether it falls back to the origin's authorization server metadata.

If you'd rather not handle any of that yourself, Intercom is one of the presets in our connector marketplace, and the end-user OAuth docs list which providers passed a live registration test and which need an app.