提供对 Intercom 对话和聊天的访问的模型上下文协议 (MCP) 服务器。该服务器允许 LLM 使用各种过滤选项查询和分析您的 Intercom 对话。
使用过滤选项查询 Intercom 对话：
日期范围（开始日期和结束日期）
客户 ID
对话状态
使用您的 Intercom API 密钥进行安全访问
丰富的对话数据包括：
基本对话细节
联系信息
统计数据（回复、重新打开）
状态和优先级信息
Related MCP server: Intercom MCP Server
克隆存储库：
git clone https://github.com/fabian1710/mcp-intercom.git
cd mcp-intercom安装依赖项：
npm install设置您的环境：
cp .env.example .env将您的 Intercom API 密钥添加到.env ：
INTERCOM_API_KEY=your_api_key_here构建服务器：
npm run build启动服务器：
npm start将服务器添加到您的 Claude for Desktop 配置中（在 macOS 上为~/Library/Application Support/Claude/claude_desktop_config.json ，在 Windows 上为%AppData%\Claude\claude_desktop_config.json ）：
{
"mcpServers": {
"intercom": {
"command": "node",
"args": ["/path/to/mcp-intercom/dist/index.js"],
"env": {
"INTERCOM_API_KEY": "your_api_key_here"
}
}
}
}重启 Claude 桌面版
使用可选过滤器搜索对讲对话。
参数：
createdAt （可选）：带有operator （例如“>”、“<”、“=”）和value （UNIX 时间戳）的对象，用于按创建日期进行过滤。
updatedAt （可选）：带有operator （例如“>”、“<”、“=”）和value （UNIX 时间戳）的对象，用于按更新日期进行过滤。
sourceType （可选）：对话的源类型（例如“电子邮件”、“聊天”）。
state （可选）：要过滤的对话状态（例如“打开”、“关闭”）。
open （可选）：布尔值，按打开状态进行过滤。
read （可选）：布尔值，按读取状态进行过滤。
示例查询：
“搜索 2024 年 1 月 1 日之后创建的所有对话”
“查找上周之前更新的对话”
“列出所有打开的电子邮件对话”
“获取所有未读对话”
服务器需要 Intercom API 密钥才能运行
API 密钥应安全地存储在环境变量中
服务器仅提供对对话的读取权限
所有 API 请求均经过适当的身份验证
通过自动重新编译启动开发模式：
npm run dev运行 linting：
npm run lint分叉存储库
为您的功能创建新的分支
进行更改
提交拉取请求
麻省理工学院
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
