Skip to main content
Everything Super Magic can do inside Inbox, it can do inside your AI client too. Thread MCP is part of Super Magic — the same governed tool layer, exposed over the Model Context Protocol so an external client (Claude, an internal agent, whatever speaks MCP) can search tickets, look up contacts, and take confirmed actions. When automation has to reach beyond Thread, you drop to webhooks and the API. This lesson covers both — the AI-native path and the code path.

Thread MCP: the desk in your own AI client

The Thread MCP server developer guide is the setup path: connect the server to an MCP-capable client, authenticate, and your client gains Thread’s tools. Because it’s the same layer as Super Magic, the same safety model comes with it:
  • Reads are free. Searching tickets, contacts, companies, and the knowledge base never changes anything.
  • Writes are confirmed and attributed. Any action that changes Thread runs under your identity and the same permission gating — write access, intents, and flows stay admin-controlled, and connector tools appear only once their integration is connected.
Thread MCP inherits your Super Magic permissions exactly. A tool you can’t run in Inbox won’t appear over MCP either — the gate is the account, not the surface.

The tool reference: what the layer can actually do

The Super Magic tool reference is the authoritative catalog of every tool Super Magic and Thread MCP expose — ticket search, contact and company lookup, notes, time entries, scheduling, approvals, recaps, and the integration tools. Treat it as your API surface for the AI-native path:
  • Building a Super Magic Agent or an external MCP workflow? The reference tells you which tool does the job and what it needs.
  • Debugging “why can’t the agent do X?” It tells you whether X is a tool at all, and whether it’s gated behind admin access or a connector sign-in.
Keep it open while you build. Most “the agent won’t do this” questions are answered by one line in that reference.

Webhooks and the API: automation outside Thread

When a workflow has to touch systems Thread doesn’t reach, you drop to the code path. Webhooks & APIs — how Thread talks to your PSA explains the plumbing that already runs the desk, and how to hook your own automation into it:
  • Webhooks are how Thread and your PSA stay in sync in near-real-time — the same signal Flows listen for. They fire on thread updates and carry the change to whatever’s subscribed.
  • APIs are how external systems read and write Thread data directly, for the integrations no in-app Flow can express.
Webhooks are near-real-time but not 100% guaranteed to deliver every event. For anything that must not be missed, reconcile against the API rather than trusting the webhook stream alone — and remember a Flow only re-evaluates a thread when it’s updated, so an internal note is the reliable way to force a re-check.

Rewst: orchestration without maintaining glue code

For cross-tool orchestration you’d otherwise hand-build, the Thread + Rewst integration connects Thread into Rewst’s automation platform. It’s the pragmatic middle path between an in-app Flow and a bespoke API service: Thread events and actions become steps in a Rewst workflow that can also touch your RMM, M365, documentation, and the rest of your stack — without you owning the integration code. Reach for Rewst when the automation spans several tools and you’d rather compose it than maintain it.

Choosing your path

Next

You’ve got the tool layer inside and outside Thread. Last lesson: extend Super Magic with connectors, package your work as reusable skills, and ship runbooks.

Build with Super Magic

Add external tools with connectors, author Skill Library skills, and run Automagically runbooks.