OpenClaw Integrations

How to Connect Intercom to OpenClaw: Setup, Models, and Workflow Guide

·21 min read

If you're searching for "how to connect Intercom to OpenClaw", the real question is usually not just whether the connection is possible. It's how to make Intercom usable inside an OpenClaw workflow with the right model, the right context, and the right level of control.

That's the practical framing.

OpenClaw gives you the orchestration layer: connectors, skills, tools, prompts, approvals, and the ability to run workflows where your team already works. Intercom provides the domain context. The integration becomes valuable when those two pieces are connected cleanly.

Intercom + OpenClaw: What's Actually Happening Here

When someone searches for "how to connect Intercom to OpenClaw," they're asking one of two questions. Either they're running OpenClaw on their own server and need the integration path, or they already use Cody (OpenClaw managed) and want to understand what's under the hood.

Intercom's data model spans conversations, contacts, companies, articles, and tickets — and the integration needs to surface the right subset in Slack without overwhelming your support team with noise. The good news: Intercom launched an official remote MCP server, and it's the cleanest path by far. The caveats: it's US-hosted workspaces only, the search DSL has a learning curve, and there are rate limit tiers that differ across Intercom plans.

Let's walk through what actually works in mid-2026.


Path A: Intercom's Official Remote MCP Server (Recommended)

Intercom hosts a remote MCP server that follows the authenticated remote MCP specification. It's available at:

https://mcp.intercom.com/mcp  (Streamable HTTP — recommended)
https://mcp.intercom.com/sse   (Legacy SSE — deprecated, backwards compat)

This is Intercom's own infrastructure. No Docker containers, no SSH tunnels, no token rotation to manage. The server translates MCP tool calls into Intercom REST API calls under the hood — and it exposes 13 tools across conversations, contacts, companies, and Help Center articles.

How this connects to OpenClaw: OpenClaw can consume remote MCP servers as tools. In your OpenClaw Gateway config, you'd add the Intercom MCP server:

{
  mcp: {
    servers: {
      intercom: {
        url: "https://mcp.intercom.com/mcp",
        transport: "streamable-http",
        auth: "oauth"
      }
    }
  }
}

Run openclaw mcp login intercom to complete OAuth, then verify the connection with openclaw mcp doctor intercom --probe. Once connected, an agent can use the Intercom data and actions allowed by the authenticated user's permissions.

⚠️ Important region limitation: The Intercom MCP server is currently only supported for US-hosted workspaces. If your Intercom workspace is hosted in the EU or Australia, the MCP server won't work. In that case, skip to Path B (REST API proxy).

Setup Steps for the Official MCP Server

Step 1: Choose your auth method. Intercom's MCP server supports two authentication approaches:

  • OAuth Flow (Recommended): Automatic browser-based authentication. Your OpenClaw agent initiates the OAuth flow, you approve it in the browser, and the server handles token refresh.
  • Bearer Token: Direct API token authentication. Generate an access token from app.intercom.com/developers with the required scopes.

For Bearer token auth, your config looks like:

{
  mcp: {
    servers: {
    intercom: {
      command: "npx",
      args: [
        "mcp-remote",
        "https://mcp.intercom.com/mcp",
        "--header",
        "Authorization:${AUTH_HEADER}"
      ],
      env: {
        AUTH_HEADER: "Bearer YOUR_INTERCOM_API_TOKEN"
      }
    }
    }
  }
}

Step 2: Verify your scopes. The MCP server requires three permission groups:

  • Read and list users and companies — for contact and company data access
  • Read conversations — for conversation data access
  • Read and write articles — for Help Center article access

If your token is missing any of these scopes, the corresponding MCP tools will fail with authentication errors rather than silently returning empty results.

Step 3: Test the connection. Use the MCP Inspector to verify:

npx @modelcontextprotocol/inspector

Connect to https://mcp.intercom.com/mcp with Transport Type: Streamable HTTP. You should see all 13 available tools. Run a test search: object_type:conversations state:open limit:5.


Path B: Intercom REST API Proxy + OpenClaw Skill File (Any Region, Full Control)

If your workspace is in the EU or Australia (MCP server doesn't support it), or you need capabilities the MCP server doesn't expose (tickets, tags, teams, webhook management), building a thin proxy around Intercom's REST API is the fallback.

Step 1: Generate an Intercom Access Token

Go to app.intercom.com/developers → Developer Hub → create a new app, then generate an access token. Choose scopes based on what your agent needs:

Scope Required For
conversations.read ✅ Required — search and read conversations
contacts.read ✅ Required — search and read contacts
companies.read Recommended — company enrichment
articles.read Optional — Help Center content lookup
tickets.read Optional — Intercom Tickets API (separate from conversations)

⚠️ Scopes have different permission models: Conversation and contact scopes use standard OAuth — the token can see what the creating admin can see. But if you're using Intercom's Tickets feature, note that tickets are a separate API surface from conversations and may require additional scopes or workspace-level feature enablement.

Use the token as a Bearer header for all requests to the regional endpoint:

Region Base URL
US https://api.intercom.io
Europe https://api.eu.intercom.io
Australia https://api.au.intercom.io

Step 2: Understand Intercom's Key API Endpoints

Intercom's REST API v2.10+ uses consistent patterns:

Resource Method Endpoint Notes
Search conversations POST /conversations/search Structured queries — filter by state, assignee, tag, date range
Get conversation GET /conversations/{id} Returns full thread with conversation parts and metadata
Search contacts POST /contacts/search Filter by email, name, external_id, custom attributes
Get contact GET /contacts/{id} Full contact profile including custom attributes, companies
List companies GET /companies Page-based pagination, optional filters by name, tag, segment
List articles GET /articles Help Center articles, page-based pagination
Create article POST /articles Creates Help Center article, title and author_id required
List tags GET /tags All tags in the workspace (not in MCP server)
List teams GET /teams Team roster with admin IDs (not in MCP server)
List admins GET /admins All teammates/admins (not in MCP server)

For conversation search, the body accepts structured filters:

{
  "query": {
    "operator": "AND",
    "value": [
      { "field": "state", "operator": "=", "value": "open" },
      { "field": "statistics.last_close_at", "operator": ">", "value": 1719532800 }
    ]
  },
  "pagination": { "per_page": 50 }
}

Step 3: Build the Proxy

Your proxy accepts simple HTTP requests from OpenClaw and translates them:

  • GET /intercom/open-conversations → searches for open conversations
  • GET /intercom/contact?email=jane@acme.com → finds a contact by email
  • GET /intercom/conversation/123 → full conversation thread
  • GET /intercom/company?name=Acme → finds a company by name
  • POST /intercom/reply → reply to a conversation (via POST /conversations/{id}/reply)

The proxy handles auth (Bearer token), cursor-based pagination, and response formatting for the model.

Step 4: Write the Skill File

Create ~/.openclaw/skills/intercom.md documenting your team's tags, assignment logic, and common query patterns:

# Intercom Skill

## Teammate Assignment
- Support team: Admin IDs 123, 456, 789
- Urgent triage: Admin ID 100 (team lead)

## Tags We Use
- "enterprise-account", "bug-report", "feature-request", "churn-risk"

## Common Queries
- **Open inbox:** GET /intercom/open-conversations
- **Customer history:** GET /intercom/contact?email={email} → then GET /intercom/conversations/{contact_id}
- **Urgent items:** GET /intercom/open-conversations?tag=churn-risk
- **Weekly report:** GET /intercom/conversations?state=closed&since=7d

## Important
- Conversations use cursor-based pagination — not page numbers
- Reply endpoint sends from the authenticated admin, not the bot
- Articles returned as HTML — strip tags before presenting to the model
- Rate limit: 10,000 req/min per app, 25,000 req/min per workspace

Path C: Community MCP Servers

Before Intercom's official MCP server launched, the community built alternatives. These can still be useful if you need capabilities the official server doesn't support or you're operating in a non-US region.

Server Status Notes
Composio Intercom MCP Third-party managed Handles auth lifecycle, adds Intercom → Slack bridge layer
Community npm packages Variable Check the MCP Registry for current options — these appear and evolve frequently

When to use a community server instead of the official one:

  • Your workspace is in the EU or Australia (official MCP server is US-only)
  • You need ticket management (Intercom Tickets API — not exposed in the MCP server)
  • You need tag and team management (not in the official MCP server's tool set)
  • You need webhook management (no MCP tool for configuring Intercom webhooks)

For OpenClaw, configure a community server:

{
  mcp: {
    servers: {
    "intercom-community": {
      command: "node",
      args: ["path/to/intercom-mcp/build/index.js"],
      env: {
        INTERCOM_ACCESS_TOKEN: { source: "env", provider: "default", id: "INTERCOM_TOKEN" }
      }
    }
    }
  }
}

Current Intercom + OpenClaw page on heycody.ink — the template before enrichment

Real Use Cases for an Intercom + OpenClaw Agent

Here's what support, success, and product teams actually build once the connection works — specific to Intercom's data model and workflows:

1. Inbox Triage Dashboard

Every morning, the agent checks the Intercom inbox and posts to #support:

📥 Inbox Status — Mon 21 Jul, 09:00 Open conversations: 47 (down from 52 yesterday) Unassigned: 8 — needs team lead attention Waiting on customer > 48h: 14 — follow-up needed Snoozed: 6 — 3 expiring today Urgent/Churn-risk: 3 with "churn-risk" tag ⚠️ Conversation #8472: Enterprise customer, 27h without response, tagged "enterprise-account" and "bug-report"

The agent searches conversations by state, checks time-since-last-customer-reply against thresholds, cross-references tags, and formats the summary. The team lead sees what needs attention in 30 seconds instead of 15 minutes of clicking through the Intercom UI.

2. Customer 360° from a Single Query

A support agent types a customer's email in Slack. OpenClaw pulls from Intercom:

  • Contact profile (name, company, role, signed up, plan, custom attributes)
  • All past conversations (open and closed) with summaries
  • Company enrichment (if a company record exists)
  • Related Help Center articles they've viewed
  • Tags across all conversations

All returned in a single Slack thread. This used to require opening Intercom, searching across three different views, and manually piecing together context. Now it's one query.

3. Weekly Support Health Report

Every Friday, the agent generates a report for the #leads channel:

📊 Support Health — Week 29 Conversations opened: 312 (↑8% WoW) Median first response time: 2.3h (↓ from 2.8h last week) Median resolution time: 14.2h (↑ from 12.1h — worth investigating) Customer satisfaction: 91% (↓ from 93%) Top conversation topics: "Billing question" (28%), "Integration setup" (22%), "Bug — dashboard" (15%) Most active customers: Acme Corp (7 tickets), Beta Inc (5), Gamma Ltd (4)

The agent uses conversation search with statistics filters, aggregates by tag or topic keyword, and compares week-over-week metrics.

4. Churn-Risk Early Warning

The agent monitors conversations tagged "churn-risk" and cross-references with account data:

🚨 Churn Risk Alert Customer: Acme Corp (Enterprise plan, $24K ARR) Conversation #9847: "Considering alternatives — your API rate limits are blocking our workflow" History: 3 open conversations this month, all related to API limits Last login: 2 days ago (active) Recommended action: Escalate to CSM, schedule call within 48h, involve product team

This combines Intercom conversation data with customer context and activity signals. The agent surfaces the pattern before a human has time to notice it across multiple conversations.

5. Product Feedback Mining for PMs

Product managers don't live in Intercom. But they need to know what customers are asking for. Once a month, the agent runs an analysis:

📋 Product Feedback Digest — July 2026 Top 5 feature requests (conversations tagged "feature-request"):

  1. Bulk actions on contacts — mentioned in 23 conversations, 4 from enterprise accounts
  2. Custom report builder — 17 conversations, mostly mid-market
  3. Slack notification granularity — 14 conversations
  4. API rate limit increase — 12 conversations, 7 from enterprise
  5. Better mobile experience — 9 conversations New this month: "Bulk actions" jumped from 7 mentions to 23 — trending up sharply.

The agent searches conversations by tag, clusters by topic keyword, and tracks volume changes over time. PMs get a structured signal from unstructured support conversations.


Intercom's MCP Server Tools (Full List)

The official MCP server at mcp.intercom.com exposes 13 tools. Here's what each one does:

Universal Search Tools

Tool What It Does
search Universal search for conversations AND contacts using a query DSL. Must specify object_type:conversations or object_type:contacts. Supports complex field-based operators (eq, neq, gt, lt, contains). Free-text search with q: parameter. Cursor-based pagination, max 150 results/page
fetch Retrieve complete details for specific resources by ID. Returns full metadata, conversation parts, custom attributes, and direct Intercom app links

Conversation Tools

Tool What It Does
search_conversations Search conversations with advanced filtering: source type, author details, state (open/closed/snoozed), team_assignee_id, admin_assignee_id, timing statistics (time_to_assignment, time_to_admin_reply, time_to_first_close) with operators (<, >, =, !=, <=, >=)
get_conversation Retrieve full conversation detail — all conversation parts, metadata, timestamps, assignment info

Contact & Company Tools

Tool What It Does
search_contacts Search contacts by ID, name, email, phone, custom attributes, email domain with flexible matching
get_contact Complete contact information including custom attributes, location data, activity timestamps
list_companies List companies with optional filters (name, company_id, tag_id, segment_id). Page-based pagination, max 60 per page
get_company Complete company details including custom attributes, segments, and tags

Help Center Tools

Tool What It Does
list_articles List all Help Center articles. Page-based pagination, 1-150 per page
search_articles Search by phrase across title and body, filter by state (published/draft), help_center_id, optional highlighting
get_article Full article including HTML body, metadata, and parent collection info
create_article Create a new Help Center article. Requires title and author_id. Optional: description, body (HTML), state, parent collection
update_article Update existing article — any of title, author, description, body, state, parent

Intercom-Specific Pitfalls (What Most Guides Miss)

These are the real-world gotchas from teams running Intercom integrations in production:

1. The MCP Server Is US-Only — And Fails Silently for Other Regions

Intercom's MCP server documentation says "currently only supported in US hosted workspaces." What it doesn't say: if you try to connect from an EU or Australian workspace, you can complete the OAuth flow successfully, but the tools return empty results. No error message, no region warning — just zero conversations, zero contacts. Fix: Check your workspace hosting region before choosing integration path. Settings → Workspace → Workspace Data Hosting Location. If it's not US, use Path B (REST API proxy) or Path C (community MCP).

2. The Query DSL Has a Learning Curve

The MCP server's search tool uses a query DSL (Domain-Specific Language) rather than structured JSON. Queries look like:

object_type:conversations state:open source_type:email team_assignee_id:15

This is powerful but error-prone. Missing the object_type: prefix silently returns zero results. Operators like contains: require a colon after the operator name (source_body:contains:"refund"). If the LLM generates a query with the wrong syntax, you get empty results — not an error. Fix: Document your common query templates in the skill file. Test queries in the MCP Inspector before deploying them in agent prompts. The DSL uses : as a field-value separator and : again inside operators — double colons in a single query are valid syntax.

3. Intercom Has TWO "Assistant" Products — They're Different

Intercom ships two AI products that sound similar but serve completely different purposes:

  • Fin AI Agent: Customer-facing AI that answers end-user questions from your Help Center. It's a chatbot your customers talk to. Powered by GPT-4 plus proprietary Intercom AI.
  • MCP Server: Developer-facing API bridge that lets AI tools (like OpenClaw agents) access your Intercom data programmatically. It's infrastructure, not a chatbot.

Teams often assume "Intercom has AI, I don't need a separate integration." But Fin is for customer self-service — it doesn't give your support team AI-powered workflow automation in Slack. The MCP server + OpenClaw handles triage, reporting, cross-tool context, and proactive monitoring — workflows Fin can't do. They're complementary, not overlapping.

4. Conversation Parts Use Cursor-Based Pagination

Long conversation threads with many parts (messages, notes, assignments) are paginated. Intercom uses cursor-based pagination — not page numbers. If your proxy only fetches the first page, you might show the agent only the first 5 messages of a 30-message thread and miss the actual resolution. Fix: Always check for pages.next.starting_after in API responses. Loop until pages.next is absent. The MCP server's search tool handles this by adding _note hints with pagination cursors, but your agent prompt needs to tell the model to follow pagination links.

5. Reply Permission Model Depends on the Auth Token

When replying to a conversation via the API, the reply is attributed to the admin whose access token you're using. If your token belongs to "Support Bot" admin and a customer asks "who am I talking to?", the reply shows "Support Bot" — not the actual support agent handling the case. Fix: If you need attributed replies, use per-agent access tokens or note clearly in your skill file: "Replies are sent from [admin name]. If attribution matters, switch to per-agent auth." Alternatively, use OpenClaw drafts that require manual review before sending.

6. Tags Are Workspace-Level — And They Disappear

Intercom tags are applied at the workspace level. If your team has 200+ tags across the workspace, the tag search becomes noisy. Worse: tags can be renamed or deleted by any admin. If your agent skill file hardcodes a tag name and someone renames it, the agent silently matches zero conversations. Fix: Don't hardcode tag names in prompts. Use the list_tags API endpoint (or /tags in Path B) to dynamically discover active tags. Refresh the tag cache weekly. Build a tag mapping in your skill file against tag IDs (which are stable) rather than display names.

7. Rate Limits Are Per-App AND Per-Workspace

Intercom's API rate limits have two tiers: 10,000 requests per minute per app, and 25,000 requests per minute per workspace. A single agent query ("list all open conversations from enterprise accounts with their contact details") can translate to 5+ API calls: list conversations, get each conversation detail, search contacts for each conversation, and fetch contact details. If your team has multiple agents or integrations sharing the same app token, you'll hit the per-app limit before the workspace limit. Fix: Use a dedicated app/token for your OpenClaw agent. Cache data that doesn't change frequently (company details, contact profiles). The MCP server's search returns IDs you can batch-fetch with fetch — one call for up to multiple resources instead of N individual calls.


Decision Matrix: Which Path Should You Take?

Scenario Best Path Why
US workspace, standard support workflows Official MCP — Path A Zero infrastructure, 13 tools, OAuth, maintained by Intercom
EU or Australia workspace Proxy — Path B MCP server is US-only
Small team (5-15), want Intercom agent in Slack today Cody Zero setup, full OpenClaw power, Intercom connected in minutes
Need ticket management (Intercom Tickets) Proxy — Path B Tickets API not in MCP server tool set
Help Center content management Official MCP — Path A create_article and update_article tools included
Headless/automated agent (nightly triage) Proxy — Path B or Community MCP — Path C Bearer token auth avoids OAuth PKCE browser flow
Multi-tool context (Intercom + Jira + Salesforce) Official MCP — Path A OpenClaw consumes multiple MCP servers simultaneously
Need tag/team/admin management Proxy — Path B Not in MCP server

Related Pages

What “Connect Intercom to OpenClaw” Actually Means

In practice, connecting Intercom to OpenClaw usually involves four layers:

  • Authentication so OpenClaw can securely access Intercom
  • Tooling or proxy endpoints that expose the right Intercom actions and data
  • Skills/instructions that tell OpenClaw how to reason over Intercom context
  • Model selection so the assistant uses the right LLM for the job

That last piece matters more than most people expect.

Which Models Can You Use?

OpenClaw is model-flexible, so a Intercom integration does not need to be tied to a single provider. Depending on your setup, teams commonly want to use:

  • OpenAI models for broad reasoning, structured extraction, and tool use
  • Anthropic models for writing, analysis, and long-context work
  • Google models for multimodal and large-context workflows
  • Other model backends if your OpenClaw environment exposes them

Model names and availability change frequently, so check your OpenClaw model catalogue rather than copying a version from a guide. The practical point is that you can connect Intercom once, then choose a supported model for each workflow.

For example:

  • Use Claude for nuanced summarisation or drafting
  • Use OpenAI for structured extraction, tool-heavy workflows, or general-purpose copiloting
  • Use Gemini when multimodal or very large context windows matter

A Good Integration Pattern for Intercom

A strong Intercom + OpenClaw setup usually looks like this:

  1. OpenClaw receives a request in chat or from an automation
  2. It calls the right Intercom endpoint or proxy
  3. The selected model reasons over the returned context
  4. OpenClaw returns an answer, draft, classification, or action
  5. High-risk actions stay behind approvals or structured guardrails

That is what makes the setup operational rather than just experimental.

Step-by-Step: Connect Intercom to OpenClaw

Step 1: Create an Intercom Access Token

Go to app.intercom.com/developers, create a new app, and generate an access token with the scopes you need (Conversations read, Contacts read at minimum). Use this as a Bearer token for all API requests to https://api.intercom.io.

Step 2: Use the Search Conversations Endpoint

The /conversations/search endpoint accepts structured queries — filter by state (open, closed, snoozed), assignee, tag, and more. For contact history, the /contacts/{id}/conversations endpoint returns all conversations for a specific customer.

Step 3: Build the Proxy and Skill File

Build your proxy around conversation search and contact lookup. Write ~/.openclaw/skills/intercom.md with your team's tag names and assignment team names — Intercom uses human-readable labels that Claude can work with directly.

Model-Specific Workflow Ideas

Intercom + OpenAI

Use this when you want a strong general-purpose setup for extraction, classification, action planning, and tool-driven workflows around Intercom.

Intercom + Claude

Use this when you want better writing quality, clearer summaries, stronger nuance, and reliable long-context reasoning over Intercom data.

Intercom + Gemini

Use this when the workflow benefits from large context windows, multimodal inputs, or Google-native ecosystem alignment.

Common Mistakes

Most teams do not fail because the model is bad. They fail because:

  • the Intercom connection is too thin
  • the model lacks the right live context
  • prompts are vague
  • no structured outputs are enforced
  • permissions and approvals are skipped
  • one model is forced to do every job, even when another would be a better fit

The best setup is usually one integration layer, multiple model options, and clear guardrails.

Challenges and Caveats

Rate Limits Are Strict on Lower Plans

Intercom's API rate limits are 500–1000 requests per minute depending on plan. Conversation search can involve multiple paginated requests for large inboxes. Cache results where possible.

Conversation History Has Pagination

Long conversation threads are paginated. If a customer has been in contact many times, your proxy may need to handle cursor-based pagination to retrieve the full history.

Want Intercom Connected to OpenClaw Without Building the Whole Stack Yourself?

Cody gives your team an Intercom AI assistant in Slack, so people can review inbox health, summarise conversation history, draft replies, and surface recurring customer pain without managing access tokens or building the inbox workflow glue themselves.

Get started with Cody →


Related OpenClaw Guides


Looking for a more workflow-first angle? See: Intercom AI Automation and Intercom AI Assistant.

More Intercom Resources