MuninX MCP is live.
That means compatible AI clients can now work with your MuninX support data through your MuninX permissions. Not by screenshotting the queue. Not by asking someone to paste the last twelve messages into a chat window like a medieval integration pattern. Through a proper MCP connection.
The practical version: an AI client such as Codex or Claude Code can inspect tickets, read ticket messages, search visible support history, draft replies, and query ticket analytics.
The human version: it can help with the support work around the answer. The digging, sorting, checking, and “what else happened with this customer?” part that eats time before anyone writes the useful sentence.
What shipped
MuninX now has a remote MCP server at https://api.muninx.com/mcp.
After setup, a compatible AI client can use MuninX tools for common ticket workflows:
- list and inspect tickets
- create and update tickets
- read ticket messages
- create ticket messages
- search visible ticket content
- query ticket analytics
That is deliberately close to the support work small teams already do. Which tickets matter first? What happened in this thread? Have we seen this issue before? What is the queue doing this week?
MCP is useful because those questions are usually scattered across tabs, memory, and someone saying “I think we answered this last month” with the confidence of a person about to be humbled by search.
It uses your MuninX permissions
MuninX MCP uses a personal API token. The token belongs to a MuninX user, and MCP requests follow that user’s tenant, role, and permissions.
That boundary matters.
An admin, an agent, and a customer do not automatically see the same records or have the same write permissions. Connecting an AI client does not promote the user into a tiny all-seeing support monarch. The AI client can work with what the token owner is allowed to access.
For example, customer-scoped access rules still apply, and customers do not receive internal notes through MCP when their role should not allow them to see those notes.
This is the boring security sentence that becomes extremely interesting the first time someone asks, “Can I let a customer connect their AI assistant?”
MCP is not the in-app AI button
MuninX already has built-in AI-assisted features inside the app for draft replies and response improvement. Those are available to admins and agents whose agent type is AI-assisted, and MuninX covers the underlying AI usage for those in-app features as part of the AI-assisted agent subscription.
MuninX MCP is different.
MCP is an integration interface for external AI clients. MuninX provides authenticated access to tickets, messages, search, and analytics. The external AI client handles the model interaction, and that external AI client or provider handles its own usage and billing.
That distinction is worth repeating because pricing confusion is where good product updates go to develop a limp:
- Built-in MuninX AI-assisted replies happen inside MuninX.
- MuninX MCP connects an external AI client to MuninX.
- MCP usage is not the same thing as a MuninX AI-assisted agent subscription.
- External AI-client costs belong to the external AI client or provider.
The result is more flexible, but also more explicit. If you connect Codex, Claude Code, or another compatible MCP client, you are choosing that client as the place where the AI work happens.
What it is good for
The best first MCP workflows are not dramatic.
They are support questions with a lot of context gathering:
- Which tickets created today need attention first?
- What are the urgent tickets waiting on?
- Have we answered this issue before?
- What does this customer’s recent support history look like?
- Can you draft a reply using the visible thread context?
- What did ticket volume look like by priority over the last 30 days?
Those are not replacements for judgment. They are ways to reduce queue archaeology.
An AI client can read across the records it is allowed to access and return a starting point. The support person still decides whether the summary is accurate, whether the draft is safe to send, and whether the customer needs a different answer than the historical pattern suggests.
Support work is full of sentences that look reusable until the final detail changes the answer. The machine can fetch the context. The person still owns the promise.
What it is not
MuninX MCP is not a live autonomous support agent.
It does not mean MuninX is now answering customers without review. It does not mean every user has built-in AI-assisted replies. It does not mean an external AI client can ignore MuninX permissions because the prompt was phrased confidently.
It is also not meant to replace the setup documentation. Use the MuninX MCP guide for token creation, Codex setup, Claude Code setup, and exact configuration.
The blog version is simpler: MCP gives your AI client a supported way to work with MuninX support data, under your MuninX access rules.
That is enough to make support work less tab-heavy without pretending that customer communication no longer needs an accountable human.
A useful first prompt
Start with a read-only workflow:
Which tickets created today need my attention first?
That prompt is good because the answer can be checked quickly. You can compare the result with the queue, inspect the reasoning, and see whether the AI client understands the shape of your support work before asking it to draft anything customer-facing.
Then move to workload summaries, related-history searches, and reply drafts. Keep the first few workflows boring enough that mistakes are visible.
Support automation should earn trust in small, inspectable steps. Grand automation usually arrives wearing a cape and leaves behind a permissions review.
Set up MuninX MCP from the official guide, connect a compatible client, and begin with the queue question your team already asks every morning.