Support teams already living in an assistant
If your L1 team drafts replies and triages through Claude or Cursor, this adds case briefing to the same window they are already working in. No new tab, no separate tool to remember.
Home › Integrations › MCP server
Model Context Protocol · Open source
CaseMargin's MCP server gives Claude, Cursor, or any MCP-compatible client two support tools it can call on its own: turn a ticket thread into a structured case brief, and score whether that ticket is ready to escalate to L2. Paste a thread, ask a question in plain language, get structured analysis back.
MIT licensed · Node 18+ · one npx line to install · no key needed to start
Support teams increasingly work through an assistant that has access to the helpdesk. Ask it about a ticket and it will happily summarise the thread — which is the least useful thing it could do, because a summary is just the thread again, shorter.
What the next agent actually needs is a judgement: what is broken, what has already been tried and what each attempt showed, and the single next action. That is a different task from summarisation, and general-purpose models do it inconsistently because nothing in the prompt tells them what a good case brief looks like.
An MCP server fixes that by moving the reasoning out of the prompt and into a tool. Your assistant stops improvising a format and starts calling something that returns the same structure every time.
The positioning, plainly: this server does not connect to Zendesk, Freshdesk, or anything else. It takes ticket content as input and returns structured analysis. That makes it composable — a helpdesk MCP server fetches the ticket, and this one reasons about it.
Both take one input — the ticket content — and return parseable JSON, not a text blob.
Generate a structured case brief from a support ticket thread. Returns a Quick Scan block — assessment, next step, status — followed by the full breakdown: current problem, actions already taken with what each one showed, and key context. Metadata reports the compression ratio, because a brief that is not meaningfully shorter than the ticket has not done its job.
Analyse whether a ticket is ready to hand to L2. Returns a 0–100 readiness score, a breakdown across five dimensions — problem clarity, troubleshooting evidence, business impact, next action, billing defensibility — plus the questions L2 will ask anyway and the specific items still missing.
There is no third tool, and that is a design decision rather than a roadmap gap. Tool-selection accuracy falls off as an agent's tool list grows, so two capabilities with obviously different jobs get picked correctly far more often than six overlapping ones.
Six lines of config. There is no build step.
For Claude Desktop that is claude_desktop_config.json. Paste the six lines below and quit the app rather than closing the window — the config is read at process start. Cursor and Claude Code take the same shape.
Nothing to install beforehand. The first run pulls casemargin-mcp-server from npm and caches it. All it needs is Node 18 or later, which ships with any current install.
You never call the tools by name. Paste a thread and ask what is happening with the ticket, or whether it is ready to escalate — the model picks the right tool and returns the structure.
Drop this into claude_desktop_config.json and restart. There is nothing to install first — npx fetches the package on the first run, so there is no path on your machine to get wrong.
The API key is optional. Without it, brief generation runs on the anonymous per-IP allowance and escalation scoring works normally — scoring is free and takes no key at all. Setting a key raises briefs to your account quota; drop the whole env block to run keyless.
claude_desktop_config.json
{
"mcpServers": {
"casemargin": {
"command": "npx",
"args": ["-y", "casemargin-mcp-server"],
"env": {
"CASEMARGIN_API_KEY": "your-api-key-here"
}
}
}
}or run it from source
$ git clone https://github.com/Casemargin/casemargin-mcp-server.git
$ cd casemargin-mcp-server
$ npm install
$ npm run buildTwo questions, asked in plain language. You never name the tool.
“What's happening with this ticket?” — paste the thread underneath the question. The assistant recognises this as a briefing task, calls generate_case_brief, and comes back with a Quick Scan it can act on: the assessment, the single next step, and the case status — then the full breakdown of what was tried and what each attempt showed.
“Is this ticket ready to escalate?” — the same thread, a different question, so the assistant calls check_escalation_readiness instead. On a real VPN ticket with clear symptoms but thin evidence, it returns 56/100 — borderline: business impact scores 90 because the SLA and the affected executive are stated, while next action scores 30 because the notes never make an explicit ask of L2. That gap is the actionable part.
The second case is the one worth dwelling on. A readiness score is not a gate — it is a list of what the ticket is missing, produced before L2 bounces it back. The setup tutorial walks through that exact scoring run, dimension by dimension, with the real output.
Three groups, roughly, and they want different things from it.
If your L1 team drafts replies and triages through Claude or Cursor, this adds case briefing to the same window they are already working in. No new tab, no separate tool to remember.
You get case reasoning as a callable tool with a typed output schema, so your agent can branch on readiness or read missing_items field by field instead of parsing prose.
Billing defensibility is one of the five scored dimensions. Techs find out a note will not survive a client dispute while the ticket is still open, not at invoice time.
The sidebar app only helps Zendesk accounts. The MCP server is helpdesk-agnostic by construction — if you can copy the thread, you can brief it.
Pair it with a helpdesk MCP server: that one fetches the ticket, this one judges it. Neither has to know the other exists, which is the point of the protocol.
Escalation scoring is free, anonymous and keyless. You can point a client at the server and see real output without creating an account.
It calls the same API the web app does. The prompt logic is not duplicated inside the server — it is a thin client over the endpoints behind the brief builder and the Escalation Readiness Score tool. When the brief format improves, the MCP server benefits without a release.
Stdio transport only. The server runs as a local process owned by your client. There is no remote endpoint to host, authenticate, or leave exposed.
Errors come back as errors. Unreachable API, exhausted quota, rejected key, a request past the 30-second timeout — each returns a clear message through the protocol instead of crashing the server and dropping your client's connection.
Input is validated before it leaves your machine. Empty strings, anything under 10 characters, and anything past the endpoint's ceiling are rejected locally with a specific message, so you learn the input was wrong immediately rather than after a round trip.
The Model Context Protocol is an open standard for exposing tools to AI clients. A support MCP server gives an assistant like Claude or Cursor a set of support-specific capabilities it can call on its own. The CaseMargin server exposes two: generating a structured case brief from a ticket thread, and scoring whether a ticket is ready to escalate to L2.
No, and that is deliberate. The server takes ticket content as input and returns structured analysis. It sits above the data layer, so it composes with a helpdesk MCP server rather than competing with one: that server fetches the ticket, this one reasons about it. If you want CaseMargin reading tickets directly, the Zendesk sidebar app does that.
Any client that speaks the Model Context Protocol over stdio. That includes Claude Desktop, Claude Code, and Cursor. The server is a standard Node process, so anything implementing the protocol can drive it.
Not to start. Escalation scoring is free and anonymous with no key at all. Brief generation works without a key on an anonymous per-IP allowance; setting CASEMARGIN_API_KEY raises that to your account's monthly quota and is the only reason to sign up.
Tool-selection accuracy degrades as the number of tools in an agent's context grows. Two tools with clearly distinct jobs means the model reliably picks the right one instead of guessing between near-duplicates, which matters more in practice than surface area.
Raw ticket text is never stored. For briefs generated against an account key, only the sanitized brief output is retained so your team can search its own history. Escalation scoring stores nothing beyond anonymous usage counts.
Yes, MIT licensed, on GitHub. It is a thin client over the same API endpoints the CaseMargin web app uses, so improvements to the brief format reach the MCP server without a separate release.
Add six lines to your client config and npx does the rest. Escalation scoring needs no key, so you can see real output before you decide whether any of this is worth an account.
MIT licensed · stdio transport · raw ticket text is never stored