How to Generate Case Briefs from Any AI Agent

The problem with asking an assistant to summarise a ticket

Paste a support thread into any capable model and ask what is going on, and you will get a summary. It will be accurate. It will also be roughly the thread again, in paragraph form, with the useful parts distributed evenly through it.

That is not what a case brief is. A brief is a compression with a fixed shape: what is broken, what has already been tried and what each attempt showed, and the one action the next person should take. The shape is the value — it is what lets someone triage in ten seconds instead of reading for ten minutes. And a general-purpose model will not produce a consistent shape unless something in the loop insists on one.

You can insist by pasting a long instruction block every time. Or you can move the reasoning into a tool the model calls, which is what the Model Context Protocol is for. This tutorial does the second.

Before you start

You need Node 18 or later, an MCP-compatible client, and about two minutes. This walkthrough uses Claude Desktop; Cursor and Claude Code take the same shape of configuration with a different file path.

You do not need a CaseMargin account. Escalation scoring is free, anonymous, and requires no key. Brief generation works without a key too, on an anonymous per-IP allowance — a key only raises that ceiling.

Step 1 — Add it to your config

There is no install step. The server is published to npm and listed on the official MCP Registry as com.casemargin/casemargin-mcp-server, so your client fetches it on first run via npx.

Open claude_desktop_config.json. On macOS it lives in ~/Library/Application Support/Claude/; on Windows, in %APPDATA%\Claude\. If the file does not exist yet, create it with exactly this content:

{
  "mcpServers": {
    "casemargin": {
      "command": "npx",
      "args": ["-y", "casemargin-mcp-server"],
      "env": {
        "CASEMARGIN_API_KEY": "your-api-key-here"
      }
    }
  }
}

The -y flag matters: without it, npx stops to ask for confirmation before downloading, and since nothing is attached to its stdin inside a desktop app, the server hangs instead of starting.

The env block is optional. Drop it entirely to run keyless, or paste a key from the signup page to use your account's monthly quota instead of the anonymous allowance.

Step 2 — Restart, and check the tool list

Restart Claude Desktop completely — quit the application rather than closing the window, because the config is read at process start. The first launch is slower than later ones while npm downloads the package; after that it is cached.

When it comes back, the two tools appear in the client's tool list. If they do not, the config file almost certainly has a JSON syntax error — a trailing comma or a missing brace — and most clients fail silently on that rather than telling you.

If you would rather run from source, clone the repository, run npm install && npm run build, then point command at node and args at the absolute path of the built dist/index.js. On Windows the backslashes in that path must be escaped (C:\\Users\\you\\...), because the config is JSON.

Step 3 — Ask what is happening with a ticket

You never type the tool name. Ask the question you would actually ask a colleague, and paste the thread underneath it:

What's happening with this ticket?

Customer reports VPN drops every ~30 min since Monday. Rebooted router, reinstalled client v4.2, issue persists. Firewall logs show DHCP lease renewing every 30 min. Customer on Premium SLA, CFO affected. Will escalate if not fixed by Friday.

The assistant recognises this as a briefing task and calls generate_case_brief. What comes back is not prose — it is structured JSON with three blocks, which the client then renders for you.

The Quick Scan is the part you read first: an assessment of what the case is and how serious it is, the single next step, and a status line. On the ticket above, the assessment ties the disconnects to the 30-minute DHCP lease renewal rather than restating the symptom, and the next step is to extend the lease time on the affected scope and confirm whether the drops track renewals.

Underneath it, the full brief carries the current problem, the actions already taken with what each one showed, and the key context — the SLA tier, the affected executive, the Friday deadline. And metadata reports the compression ratio, which exists because a brief that is not meaningfully shorter than the ticket has failed at its only job.

Because the output is structured rather than a text blob, an agent building on top of this can read quick_scan.next_step on its own and act on it, instead of parsing a paragraph and hoping.

Step 4 — Ask whether it is ready to escalate

Same thread, different question, and the assistant picks the other tool:

Is this ticket ready to escalate to L2?

This is the call that changes behaviour, so here is the real output from the exact ticket above — not an illustration:

Actual output from check_escalation_readiness, rendered as HTML

How to read that score

The headline number is the least interesting thing on the card. What matters is the shape of the bars, and this ticket has a very common shape: impact is loud and the ask is silent.

Business impact scores 90 because the notes state the SLA tier, name the affected executive, and give a deadline. That is the part techs rarely forget, because it is the part that feels urgent to write down.

Next action scores 30 for the opposite reason. Nowhere in the ticket does anyone say what they want L2 to do. "Will escalate if not fixed by Friday" is a threat, not a request. An L2 engineer picking this up has to decide for themselves what they were handed, which is exactly where escalations bounce.

Billing defensibility scores 40 because the actions are named but not timed. "Rebooted router, reinstalled client" with no timestamps and no durations is unbillable in a dispute — you cannot invoice against work you cannot evidence. For an MSP that number is not a documentation nicety, it is revenue.

The four predicted questions are the practical payoff. Answer them before escalating and the ticket stops being borderline, because the answers close the two weak dimensions directly. That is the difference between a score and a gate: this is a to-do list produced ten minutes before L2 would have produced it as a rejection.

When something goes wrong

The tools do not appear after restart. Almost always malformed JSON in the config. Validate the file, then confirm the server itself runs by executing npx -y casemargin-mcp-server in a terminal — a working server prints a startup line to stderr and then waits for input. If that works but the client still shows nothing, check you quit the app rather than closing its window.

It hangs on first launch and never connects. Two usual causes: the -y flag is missing, so npx is waiting on a confirmation prompt nobody can answer; or the machine is offline or behind a proxy that blocks the npm registry, so the first-run download never completes. Later launches use the cache and are unaffected.

The tool returns a validation error. Input under 10 characters is rejected on purpose, as is anything past the endpoint's ceiling. Escalation scoring caps at 20,000 characters and briefing at 50,000, and both are checked locally so you find out immediately rather than after a round trip.

The call times out. Generation normally lands in a few seconds; the client gives up at thirty and says so. A timeout is nearly always transient — retry before investigating.

None of these crash the server or drop the client's connection. Errors come back through the protocol as messages, which is a deliberate design choice: a failed tool call should cost you one retry, not a restart.

Why a tool instead of a good prompt

You could paste a long instruction block ahead of every ticket and get comparable output. The reason not to is consistency across people and time.

A prompt lives in whoever's clipboard wrote it. It drifts, it gets shortened by the person in a hurry, and it produces a slightly different structure for every member of the team. Briefs stop being comparable, and once they are not comparable, people go back to reading threads — because a brief you cannot trust the shape of is just another thing to check.

A tool returns the same schema every time regardless of who called it or how they phrased the question. That is what makes the output something a team can build a habit on, and what makes it something an agent can branch on programmatically.

There is a second reason, less philosophical: the server is a thin client over the same API endpoints the web brief builder uses. The prompt logic lives in one place. When it improves, every surface improves at once — the web app, the Zendesk sidebar app, and your local MCP server — without anyone reinstalling anything.

Where this fits

The MCP server is the right surface when your team already works inside an assistant and the tickets come from somewhere that is not Zendesk, or from several somewheres. It is helpdesk-agnostic by construction: if you can copy the thread, you can brief it.

If you are on Zendesk and want briefs without copying anything, the sidebar app reads the ticket you already have open, including internal notes. If you just want to see the scoring engine without installing anything at all, the Escalation Readiness Score tool runs the same analysis in a browser tab, free and without signup.

Same engine underneath all three. The only question is which window you want it in.