Intercom MCP Server Cursor IDE Setup (2026)

How do you set up the Intercom MCP server in Cursor? Intercom publishes an official hosted server at https://mcp.intercom.com/mcp (US workspaces) or https://mcp.eu.intercom.com/mcp (EU workspaces), reached through the mcp-remote proxy since Cursor's MCP config expects a local command entry even for a remote target. Connect via OAuth for the simplest setup, or with a Bearer token in an Authorization header if you're authenticating a non-interactive environment. Once it's running, Cursor can search and read conversations, contacts, companies, and help center articles — and create or update articles — without you switching to the Intercom inbox.

This is genuinely useful mid-development: pulling a real customer conversation or a help center article's current wording into your editor while you're fixing the bug that conversation is about, instead of reconstructing the context from a support ticket ID and a separate browser tab.

What You Can Do With Intercom MCP in Cursor

The official server is US-hosted-workspace focused for the primary endpoint, with a separate EU endpoint for EU-hosted workspaces — use the one matching where your Intercom workspace actually lives, not just your own location.

Prerequisites

Method 1: OAuth via mcp-remote (Recommended)

Add this to ~/.cursor/mcp.json:

{
  "mcpServers": {
    "intercom": {
      "command": "npx",
      "args": ["mcp-remote", "https://mcp.intercom.com/mcp"]
    }
  }
}

Restart Cursor. On first use, mcp-remote opens a browser window for Intercom's OAuth authorization — sign in, approve the requested scopes, and the session persists without a token in your config file. This is the simpler route for an individual developer's local setup.

Method 2: Bearer Token (Non-Interactive Environments)

If you need a setup that doesn't depend on an interactive browser OAuth step — for example, a shared or scripted environment — use a Bearer token instead:

{
  "mcpServers": {
    "intercom": {
      "command": "npx",
      "args": [
        "mcp-remote",
        "https://mcp.intercom.com/mcp",
        "--header",
        "Authorization:${AUTH_HEADER}"
      ],
      "env": {
        "AUTH_HEADER": "Bearer your-intercom-api-token-here"
      }
    }
  }
}

The token is injected as an Authorization header via mcp-remote's --header flag, referencing an env variable rather than being hardcoded directly into args — keep it in env so it doesn't end up in shell history or process listings verbatim.

Step 3: Verify the Connection

In Cursor chat, try:

Search for open Intercom conversations mentioning "checkout error"

or

Show me the current content of the help center article about password resets

A response naming real conversations or articles confirms the connection. If you're on an EU-hosted Intercom workspace and nothing comes back, double-check you're pointing at mcp.eu.intercom.com rather than the US endpoint — a US-endpoint connection against an EU workspace typically just returns nothing rather than a clear error.

Practical Workflows

Bug context before fixing it

Find the Intercom conversation where a customer reported the export button not working, and summarize exactly what they described happening

Docs-code consistency check

I just changed how the API rate limit works — show me the current help center article that describes rate limits so I can tell if it needs updating

Support-driven prioritization

Search conversations from the last 7 days for anything mentioning "crash" or "won't load", and group them by which feature they're about

Article update from a code change

Update the help center article on webhook retries to reflect that we now retry 5 times instead of 3, matching the article's existing tone and structure

Troubleshooting

OAuth popup never appears
Confirm mcp-remote is resolvable via npx (Node.js 18+ installed) and that you're using Method 1's config exactly — a malformed args array is the most common reason the proxy fails silently instead of opening the browser.

Bearer token config connects but every call is "unauthorized"
Check that the token has the scopes the tool you're calling actually needs — conversations.read doesn't grant access to help center article writes, for example. Intercom's token scopes are additive per-capability, not all-or-nothing.

Wrong region, empty results
US-hosted and EU-hosted Intercom workspaces are separate systems behind separate endpoints. If your workspace is EU-hosted, use https://mcp.eu.intercom.com/mcp in both methods above instead of the US URL.

Article writes don't reflect Intercom's actual formatting
Help center articles in Intercom support rich formatting beyond plain text. If a generated update looks structurally different from what you'd get hand-editing in Intercom's article editor, ask Cursor to read the article's current raw content first and match its existing formatting pattern rather than generating from scratch.

Frequently Asked Questions

Q: Should I use OAuth or a Bearer token?
A: OAuth (Method 1) is the simpler default for an individual developer working locally — no token to generate or store. Use the Bearer-token route (Method 2) for non-interactive setups where a browser-based OAuth flow isn't practical, or when you want a token you can independently scope and revoke.

Q: Does the Intercom MCP server work with EU-hosted workspaces?
A: Yes, but through a separate endpoint — https://mcp.eu.intercom.com/mcp instead of the US default. Using the wrong region's endpoint for your workspace typically produces empty results rather than a clear error, so this is worth checking first if nothing comes back.

Q: Can Cursor write to Intercom, or is this read-only?
A: It supports both. Conversations and contacts are primarily read operations in most workflows, while help center articles support create and update as well. Review generated article content before it goes live, the same as any other write-capable MCP server.

Q: What Intercom scopes does a Bearer token need?
A: It depends on what you want Cursor to do — conversations.read and contacts.read for lookups, plus articles.read (and a corresponding write scope) if you want help center article access. Scope the token to only what your workflow actually uses.

Q: Is this the same as Intercom's Fin AI agent?
A: No — Fin is Intercom's own customer-facing AI agent product. The MCP server described here connects a third-party AI tool like Cursor to your Intercom data for internal, developer-facing workflows; it's a different integration surface from Fin.

Related Guides

---