Read Intercom conversations and contacts during a Sazabi investigation

Last verified on Nov 8, 2026.

A spike in support chats is often the first sign of a production problem, and the chat text carries details your logs lack: what the customer clicked, which email address they use, what they expected. The Sazabi agent can read Intercom while it searches your logs, so the question "who is reporting this" and the question "what is the service doing" get answered in one thread.

What the Sazabi agent can do with Intercom

Sazabi connects to Intercom's hosted server at mcp.intercom.com/mcp using an Intercom API access token. Intercom's server offers 14 tools, and these are the ones that matter in an investigation:

• search takes a small query language. You name an object type, then fields: object_type:conversations state:open source_type:email, or object_type:contacts email_domain:"example.com". It also does free-text search with q:.
• fetch returns the full record for an ID that search gave back, including conversation parts and custom attributes.
• search_conversations and get_conversation filter by state (open, closed, snoozed), assignee fields, author email, and timing statistics such as statistics_time_to_admin_reply.
• search_contacts, list_companies and get_company resolve a customer to their records.
• search_articles, list_articles and get_article read your help center.

Sazabi's docs describe the connector as a way to read support context. Intercom's server also has create_article, update_article and add_internal_note. The note is visible to teammates only, and Intercom states the tool cannot send customer-visible replies. Results come back in pages of up to 150, with a default of 5, so the agent asks for a larger limit: when it needs a count.

Questions it answers

• How many open conversations mention this error text, and when did the first one arrive?
• Which contacts at a given email domain wrote in during the incident window?
• What did the customer say in the conversation that was assigned to the platform team?
• Is there a help article that tells customers to do the thing that breaks?
• Which conversations are slow to get a first admin reply?

A worked example: tying chats to a failing deploy

Your logs show a rise in 500s on /api/export starting at 16

Search Intercom for open conversations that mention "export" and started after
16:00 UTC today. For each one, get the contact's email domain and the customer's
own words. Then compare the first message times with the 500s in our logs.

The agent runs search with object_type:conversations, state:open and source_body:contains:"export", adds a larger limit, and reads the results. For each conversation it calls get_conversation for the parts, and get_contact for the contact. Then it queries your logs for the same window and lines the timestamps up.

What you get is a shortlist, not a root cause. If the first chat lands a few minutes after the first 500, the deploy is a strong suspect, so ask it to check the commit history through the GitHub integration. If chats started an hour before the errors, the logs are missing something, such as a failure in a client the service never sees. The contact domains tell you whether the problem is one customer or many. When you want the support team to know, you can have the agent write an internal note on the relevant conversation, which is visible to teammates only.

How it fits with other integrations

Support context is more useful when the thread can also reach where the team talks and tracks work. Slack hosts the investigation and Linear holds the follow-up ticket, and Pylon covers teams whose support runs there instead. Browse everything under integrations or check pricing.