Un servidor de Protocolo de Contexto de Modelo (MCP) que proporciona acceso a conversaciones y chats de Intercom. Este servidor permite a los LLM consultar y analizar sus conversaciones de Intercom con diversas opciones de filtrado.
Consultar conversaciones de Intercom con opciones de filtrado:
Rango de fechas (fechas de inicio y finalización)
ID de cliente
Estado de la conversación
Acceso seguro usando su clave API de Intercom
Datos de conversación enriquecidos que incluyen:
Detalles básicos de la conversación
Información del contacto
Estadísticas (respuestas, reaperturas)
Información sobre el estado y las prioridades
Related MCP server: Intercom MCP Server
Clonar el repositorio:
git clone https://github.com/fabian1710/mcp-intercom.git
cd mcp-intercomInstalar dependencias:
npm installConfigura tu entorno:
cp .env.example .envAgregue su clave API de Intercom a .env :
INTERCOM_API_KEY=your_api_key_hereConstruir el servidor:
npm run buildIniciar el servidor:
npm startAgregue el servidor a su configuración de Claude for Desktop ( ~/Library/Application Support/Claude/claude_desktop_config.json en macOS o %AppData%\Claude\claude_desktop_config.json en Windows):
{
"mcpServers": {
"intercom": {
"command": "node",
"args": ["/path/to/mcp-intercom/dist/index.js"],
"env": {
"INTERCOM_API_KEY": "your_api_key_here"
}
}
}
}Reiniciar Claude para escritorio
Busca conversaciones de Intercom con filtros opcionales.
Parámetros:
createdAt (opcional): Objeto con operator (por ejemplo, ">", "<", "=") y value (marca de tiempo UNIX) para filtrar por fecha de creación.
updatedAt (opcional): Objeto con operator (por ejemplo, ">", "<", "=") y value (marca de tiempo UNIX) para filtrar por fecha de actualización.
sourceType (opcional): Tipo de fuente de la conversación (por ejemplo, "correo electrónico", "chat").
state (opcional): Estado de la conversación por el que filtrar (por ejemplo, "abierto", "cerrado").
open (opcional): booleano para filtrar por estado abierto.
read (opcional): booleano para filtrar por estado de lectura.
Consultas de ejemplo:
Buscar todas las conversaciones creadas después del 1 de enero de 2024
"Encuentra conversaciones actualizadas antes de la semana pasada"
"Enumerar todas las conversaciones de correo electrónico abiertas"
Obtener todas las conversaciones no leídas
El servidor requiere una clave API de Intercom para funcionar
La clave API debe almacenarse de forma segura en variables de entorno
El servidor sólo proporciona acceso de lectura a las conversaciones.
Todas las solicitudes de API se realizan con la autenticación adecuada.
Iniciar el modo de desarrollo con recompilación automática:
npm run devEjecutar linting:
npm run lintBifurcar el repositorio
Crea una nueva rama para tu función
Realiza tus cambios
Enviar una solicitud de extracción
Instituto Tecnológico de Massachusetts (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
