Asking an assistant to analyse support conversations means many queries over the same window, and doing that through the API is slow enough that you stop asking. Holding the corpus locally changes what kinds of question are worth asking — you can iterate on a search instead of budgeting for it. The trade is a copy of your customer conversations sitting on the machine that runs it, and a first sync you have to wait through before anything is answerable.
An Intercom analytics server that keeps conversations locally rather than calling the API on every question. A background sync keeps the cache fresh, requests are served from SQLite, and stale timeframes trigger an update for next time. Storage is around 2KB per conversation, and search accepts natural-language timeframes like "last 7 days".
- `search_conversations` searches message text with a natural-language `timeframe`, a `customer_email` filter and a `limit`
- `get_conversation` returns the full detail of one conversation by ID
- `sync_conversations` triggers a sync manually, with `force` for a full pass
- `get_server_status` reports server state and statistics
- A local SQLite store with an optimised schema, so repeat questions do not re-hit the API
An Intercom access token, set as `INTERCOM_ACCESS_TOKEN`. Python and a checkout: create a virtualenv and `pip install -e .` (package `fast-intercom-mcp`, version 0.3.0), then `fast-intercom-mcp init`, `fast-intercom-mcp sync --force --days 7` to seed the cache, and point your client at `fast-intercom-mcp start`. Sync freshness and the background interval are set through `FASTINTERCOM_MAX_SYNC_AGE_MINUTES` and `FASTINTERCOM_BACKGROUND_SYNC_INTERVAL`, or the config file at `~/.fast-intercom-mcp/config.json`.
One command plus a key — fast-intercom-mcp start, then supply credentials