The MCP Intercom Server allows querying and analyzing Intercom conversations with various filtering options:
Search conversations using filters like date range (creation/update dates), customer ID, conversation state, source type, open status, and read status
Fetch all conversations from the last week using a dedicated tool
Access rich conversation data including contact information, statistics (responses, reopens), state, and priority information
Securely access the server using an Intercom API key stored in environment variables
Integrate with Claude for Desktop for enhanced querying capabilities
Provides access to Intercom conversations and chats with filtering capabilities by date range, customer ID, conversation state, and other attributes. Enables querying and analyzing conversation data including contact information, statistics, and state information.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@MCP Intercom Server show me all open conversations from the last 7 days"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
A Model Context Protocol (MCP) server that provides access to Intercom conversations and chats. This server allows LLMs to query and analyze your Intercom conversations with various filtering options.
Query Intercom conversations with filtering options:
Date range (start and end dates)
Customer ID
Conversation state
Secure access using your Intercom API key
Rich conversation data including:
Basic conversation details
Contact information
Statistics (responses, reopens)
State and priority information
Related MCP server: Intercom MCP Server
Clone the repository:
git clone https://github.com/fabian1710/mcp-intercom.git
cd mcp-intercomInstall dependencies:
npm installSet up your environment:
cp .env.example .envAdd your Intercom API key to .env:
INTERCOM_API_KEY=your_api_key_hereBuild the server:
npm run buildStart the server:
npm startAdd the server to your Claude for Desktop configuration (~/Library/Application Support/Claude/claude_desktop_config.json on macOS or %AppData%\Claude\claude_desktop_config.json on Windows):
{
"mcpServers": {
"intercom": {
"command": "node",
"args": ["/path/to/mcp-intercom/dist/index.js"],
"env": {
"INTERCOM_API_KEY": "your_api_key_here"
}
}
}
}Restart Claude for Desktop
Searches Intercom conversations with optional filters.
Parameters:
createdAt (optional): Object with operator (e.g., ">", "<", "=") and value (UNIX timestamp) for filtering by creation date.
updatedAt (optional): Object with operator (e.g., ">", "<", "=") and value (UNIX timestamp) for filtering by update date.
sourceType (optional): Source type of the conversation (e.g., "email", "chat").
state (optional): Conversation state to filter by (e.g., "open", "closed").
open (optional): Boolean to filter by open status.
read (optional): Boolean to filter by read status.
Example queries:
"Search for all conversations created after January 1, 2024"
"Find conversations updated before last week"
"List all open email conversations"
"Get all unread conversations"
The server requires an Intercom API key to function
API key should be stored securely in environment variables
The server only provides read access to conversations
All API requests are made with proper authentication
Start development mode with auto-recompilation:
npm run devRun linting:
npm run lintFork the repository
Create a new branch for your feature
Make your changes
Submit a pull request
MIT
Fetch all conversations from the last week (last 7 days)
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions the action ('fetch') but doesn't specify whether this is a read-only operation, if it requires authentication, how results are returned (e.g., pagination, format), or any rate limits. For a tool with zero annotation coverage, this leaves significant behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core functionality ('fetch all conversations from the last week') with a clarifying parenthetical ('last 7 days'). There is zero wasted text, making it highly concise and well-structured for quick understanding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (0 parameters, no output schema, no annotations), the description is adequate as a minimum viable explanation. It covers the basic purpose but lacks details on behavioral traits and usage context, which are needed for full completeness, especially with a sibling tool available. This results in a baseline score of 3.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description appropriately doesn't add parameter details, and the baseline for 0 parameters is 4, as it avoids unnecessary repetition while being clear about the tool's scope (time-based fetching).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('fetch') and resource ('conversations') with a specific time constraint ('from the last week (last 7 days)'), making the purpose unambiguous. However, it doesn't explicitly differentiate from the sibling tool 'search-conversations', which likely offers more flexible filtering options, preventing a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus the sibling 'search-conversations', nor does it mention any prerequisites, exclusions, or alternative scenarios. It simply states what the tool does without contextual usage advice, leaving the agent to infer when this specific time-bound fetch is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search Intercom conversations with filters for created_at, updated_at, source type, state, open, and read status
| Name | Required | Description | Default |
|---|---|---|---|
| createdAt | No | ||
| updatedAt | No | ||
| sourceType | No | Source type of the conversation (e.g., "email", "chat") | |
| state | No | Conversation state to filter by (e.g., "open", "closed") | |
| open | No | Filter by open status | |
| read | No | Filter by read status |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions the search capability and filter parameters but doesn't describe what the search returns (e.g., format, pagination), rate limits, authentication needs, or potential side effects. This leaves significant gaps for a search tool with 6 parameters.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose ('Search Intercom conversations') followed by specific filter details. Every word contributes value with no wasted text, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (6 parameters, nested objects, no output schema, and no annotations), the description is incomplete. It doesn't explain the return format, pagination, error handling, or how multiple filters interact. For a search tool with this level of detail in the schema, the description should provide more contextual guidance to compensate for missing structured data.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 67%, and the description lists the filterable fields (created_at, updated_at, source type, state, open, read), which aligns with the 6 parameters in the schema. However, it doesn't add meaningful semantic context beyond what the schema already provides (e.g., explaining how filters combine or providing examples), so it meets the baseline for moderate coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Search Intercom conversations') and resource ('conversations'), making the purpose immediately understandable. It distinguishes from the sibling 'list-conversations-from-last-week' by specifying it's a search with filters rather than a time-limited list, though it doesn't explicitly name the alternative.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context by listing specific filterable attributes (created_at, updated_at, source type, state, open, read), suggesting when to use this tool for filtered searches. However, it doesn't explicitly state when to choose this over 'list-conversations-from-last-week' or provide any exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v1.0.0list-conversations-from-last-weeksearch-conversationsThe two tools have distinct primary purposes: one fetches recent conversations by time window, while the other searches with multiple filters. However, there is some overlap since 'list-conversations-from-last-week' could be seen as a subset of what 'search-conversations' can do with a created_at filter, which might cause minor confusion.
Both tools use kebab-case and follow a verb-noun pattern (list-conversations, search-conversations), which is consistent. The addition of 'from-last-week' in the first tool name is descriptive but breaks the pure verb-noun convention slightly, though it remains readable.
With only 2 tools, the server feels under-scoped for an Intercom integration. It lacks essential operations like creating, updating, or replying to conversations, which are core to customer support workflows, making the toolset too thin for the apparent domain.
The server only provides read-only access to conversations, missing critical CRUD operations such as creating conversations, sending messages, updating conversation states, or managing users. This leaves significant gaps that will hinder agents from performing common Intercom tasks.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Memory for deep conversational context across any platform
Run AI customer support from your terminal: conversations, knowledge base, and chat widget.
Live chat + AI support inbox: list, triage, and reply to customer conversations; configure widgets.
Connect AI tools to Weav customer service. Search conversations, reply, and manage knowledge.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/fabian1710/mcp-intercom'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
