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 .envIntercom API キーを.envに追加します。
INTERCOM_API_KEY=your_api_key_hereサーバーを構築します。
npm run buildサーバーを起動します。
npm startClaude 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を再起動する
オプションのフィルターを使用して Intercom の会話を検索します。
パラメータ:
createdAt (オプション): 作成日でフィルタリングするためのoperator (例: ">"、"<"、"=") とvalue (UNIX タイムスタンプ) を持つオブジェクト。
updatedAt (オプション): 更新日でフィルタリングするためのoperator (例: ">"、"<"、"=") とvalue (UNIX タイムスタンプ) を持つオブジェクト。
sourceType (オプション): 会話のソース タイプ (例:「メール」、「チャット」)。
state (オプション): フィルタリングする会話の状態 (例: 「open」、「closed」)。
open (オプション): オープンステータスでフィルタリングするブール値。
read (オプション): 読み取りステータスでフィルタリングするブール値。
クエリの例:
「2024年1月1日以降に作成されたすべての会話を検索」
「先週以前に更新された会話を見つける」
「開いているメールの会話をすべて一覧表示する」
「未読の会話をすべて取得する」
サーバーが機能するにはIntercom APIキーが必要です
APIキーは環境変数に安全に保存する必要があります
サーバーは会話への読み取りアクセスのみを提供します
すべてのAPIリクエストは適切な認証で行われます
自動再コンパイルによる開発モードを開始します。
npm run devリンティングを実行します:
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
