Independent open-source work · Source snapshot: 6 October 2026
MCP Server for Intercom
An AI assistant needs a defined, reusable way to retrieve relevant support records from an existing system.
A TypeScript MCP server that lets AI assistants retrieve Intercom conversations and tickets through explicit search tools.
What this project demonstrates
Search tools expose customer, status and date filters through a reusable MCP interface.
- AI assistant
- MCP request
- TypeScript handler
- Intercom search API
- Structured result
Scope and contribution
Raoul developed the TypeScript server, tool handlers and Intercom integration. Intercom supplies the underlying support platform and API; the MCP SDK supplies the protocol primitives. The connected assistant performs the language-model reasoning.
Problem and constraints
Support conversations contain useful context, but an assistant needs a defined way to retrieve it. Building a separate integration for each assistant duplicates work and makes it harder to understand which data the model can access.
The server provides an MCP interface over Intercom search operations. It requires an Intercom account and an access token; the results available to the assistant depend on that account’s permissions and on the API response.
Implementation
The TypeScript entry point creates the MCP server and transport, then delegates requests to tool handlers. The documented tools cover conversations by date range, conversations by customer, tickets by status and tickets by customer.
Search parameters include dates, customer identifiers and content filters where supported. The repository documents server-side conversation filtering and a fallback for finding an email in conversation content when a matching contact is unavailable.
The boundary is deliberate: the server retrieves support data; it does not prove that an assistant’s interpretation of that data is correct. Tool responses remain evidence for the assistant to inspect, not an automatic resolution of a support issue.
Evidence and limits
The public repository contains the implementation, tool parameter documentation and setup instructions. This case study verifies that those implementation paths exist. It does not report a live query against a customer’s support account.
No customer conversations are reproduced here. The earlier website’s integration-time and weekly time-saving claims are omitted because their measurement basis was not available for verification.
Trade-offs and next test
A reusable protocol boundary reduces coupling to a particular assistant, but it still inherits API permissions, rate limits and search semantics. A valid response can be incomplete if the query is too narrow or relevant data is outside the connected account’s scope.
A useful evaluation would use a sanitised, fixed set of conversations with known retrieval targets, then check filtering, pagination, empty results and failure handling. That would measure the integration directly without treating plausible model summaries as proof of correctness.
Practical implications
The server demonstrates a tool integration that could support research across authorised support records. Retrieval is implemented; business outcomes and assistant answer quality have not been measured.
A similar integration would need permission review, a sanitised retrieval test set and checks for pagination, empty results, rate limits and API failures before use with live customer data.