Search the inbox for the vendor notice that explains an outage, from Sazabi

Last verified on Nov 8, 2026.

Some of the best evidence about a production incident arrives as email: a cloud provider's maintenance notice, a certificate expiry warning, a customer forwarding the error they saw, a payment processor's alert. Nobody puts those in the logs, and finding them means searching an inbox that is not part of the investigation. Superhuman Mail has an MCP server, and the Sazabi agent can use it to search that inbox next to your logs.

What the Sazabi agent can do with Superhuman

Sazabi connects to Superhuman Mail's hosted server at mcp.mail.superhuman.com/mcp. You authorize once in the browser over OAuth, and Sazabi refreshes the token afterward. Superhuman's tool list is large, and the read tools below are the ones an investigation uses:

• list_threads searches email threads with structured filters: From, To, Subject, Labels, Split and date.
• query_email_and_calendar takes a natural-language question and does a semantic search over email and calendar.
• get_thread returns a thread with its share status, comments and participants, and get_message fetches one message by ID.
• get_attachment fetches an attachment, which matters for notices that carry the detail in a PDF or log excerpt.
• list_labels, list_splits and list_reminders show how the inbox is organized.
• get_draft_send_status checks whether a draft you sent or scheduled has been delivered.

Superhuman also has tools that change things. create_or_update_draft writes a draft, send_draft sends mail, and Superhuman warns that it can send emails instantly, so it recommends your AI tool ask for confirmation every time. The create_shared_thread_comment tool posts a comment that can newly share a thread. Sazabi governs drafting and sending with the per-connection read-only toggle, and for an investigation the sensible setting is on.

On Superhuman's side you need a Business plan or higher, with Ask AI enabled. Enterprise accounts have MCP access off by default.

Questions it answers

• Did a vendor email a maintenance or expiry notice before these errors started?
• Which emails from this sender arrived in the hour before the incident?
• What did the customer write when they forwarded the error, and what was attached?
• Did the email we sent to the customer actually deliver?
• Which threads in the on-call label mention this service?

A worked example: errors that began right when a certificate expired

TLS handshake failures begin at 06

Search my Superhuman inbox for threads from our certificate and DNS providers in
the last 14 days with "expire" or "renew" in the subject. Open the most recent
one and tell me the domain and the date it names. Read-only: do not draft or
send anything.

The agent finds the first handshake error in your logs and shows the query. It then calls list_threads filtered by sender and subject over the date range, opens the best match with get_thread, and calls get_attachment if the notice carries a PDF. It compares the date in the notice with the log timestamps.

If the notice names api.example.com and a date a few hours before the first error, you have a very likely cause and can move straight to renewing the certificate. If the date is weeks away, the certificate is not the cause and the search was a quick way to rule it out. If nothing is in the inbox, the notice may have gone to a shared mailbox, which this search cannot see. This is also the case where the read-only setting earns its place: a mistaken reply from your own account goes out as you.

How it fits with other integrations

An inbox is a source of context, not a source of telemetry, so use it alongside the data that is. Cloudflare and AWS cover the infrastructure those notices come from, Slack hosts the thread, and Linear tracks the fix. See all connectors under integrations, or the pricing page.