Intercom 대화 및 채팅에 대한 액세스를 제공하는 모델 컨텍스트 프로토콜(MCP) 서버입니다. 이 서버를 통해 LLM은 다양한 필터링 옵션을 사용하여 Intercom 대화를 쿼리하고 분석할 수 있습니다.
필터링 옵션을 사용하여 Intercom 대화를 쿼리하세요.
날짜 범위(시작 및 종료 날짜)
고객 ID
대화 상태
Intercom API 키를 사용하여 안전하게 액세스하세요
다음을 포함한 풍부한 대화 데이터:
기본 대화 세부 정보
연락처 정보
통계(응답, 재개)
상태 및 우선 순위 정보
Related MCP server: Intercom MCP Server
저장소를 복제합니다.
지엑스피1
종속성 설치:
npm install환경 설정:
cp .env.example .env.env 에 Intercom API 키를 추가합니다.
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 (선택 사항): 열림 상태별로 필터링하기 위한 부울 값입니다.
read (선택 사항): 읽기 상태별로 필터링할 부울 값입니다.
예시 쿼리:
"2024년 1월 1일 이후에 생성된 모든 대화 검색"
"지난주 이전에 업데이트된 대화 찾기"
"모든 열린 이메일 대화 나열"
"읽지 않은 모든 대화 가져오기"
서버가 작동하려면 Intercom API 키가 필요합니다.
API 키는 환경 변수에 안전하게 저장되어야 합니다.
서버는 대화에 대한 읽기 액세스만 제공합니다.
모든 API 요청은 적절한 인증을 거쳐 이루어집니다.
자동 재컴파일로 개발 모드 시작:
npm run dev린팅 실행:
npm run lint저장소를 포크하세요
기능에 대한 새 브랜치를 만듭니다.
변경 사항을 만드세요
풀 리퀘스트 제출
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
