Skip to main content
Glama
Casemargin

CaseMargin MCP Server

Official
by Casemargin
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

CaseMargin MCP Server

CaseMargin MCP server exposes support case reasoning tools — generate structured case briefs and check escalation readiness from any MCP-compatible AI client (Claude Desktop, Claude Code, Cursor, and others). It sits above helpdesk data layers: it doesn't read tickets from Zendesk or any ticketing system — you pass ticket content in, it returns structured analysis powered by the same AI that runs casemargin.com.

Tools

generate_case_brief

Generate a structured case brief from a support ticket thread. Returns an assessment, what has been tried, current status, and recommended next step.

Input: ticket_content (string) — the full ticket thread: messages, internal notes, whatever you paste or pipe in. 10–50,000 characters.

Output (structured JSON):

{
  "quick_scan": {
    "assessment": "…what this case is about and how serious it is…",
    "next_step": "…the single action the receiving agent should take now…",
    "status": "Waiting on customer"
  },
  "full_brief": {
    "current_problem": "…symptoms, blockers, business impact…",
    "actions_taken": ["action → outcome", "…"],
    "key_context": "…customer plan, history, logs, error codes…"
  },
  "metadata": {
    "input_length": 4210,
    "brief_length": 1250,
    "compression_ratio": 0.3
  }
}

check_escalation_readiness

Analyze whether a support ticket is ready to escalate to L2. Returns a readiness score (0–100), dimensional breakdown, predicted L2 questions, and missing items.

Input: ticket_content (string) — the ticket notes to evaluate. 10–20,000 characters.

Output (structured JSON):

{
  "overall_score": 62,
  "readiness": "borderline",
  "dimensions": {
    "problem_clarity": { "score": 80, "note": "…" },
    "troubleshooting_evidence": { "score": 55, "note": "…" },
    "business_impact": { "score": 40, "note": "…" },
    "next_action": { "score": 70, "note": "…" },
    "billing_defensibility": { "score": 65, "note": "…" }
  },
  "predicted_l2_questions": ["…", "…"],
  "missing_items": ["…", "…"]
}

Related MCP server: relay

Installation

Nothing to install ahead of time — npx fetches the package on first run. Add this to your claude_desktop_config.json and restart Claude Desktop:

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

Cursor and Claude Code take the same shape of config in their own files. The config lives at ~/Library/Application Support/Claude/ on macOS and %APPDATA%\Claude\ on Windows. Quit and reopen the app rather than closing the window — the config is read at process start.

The API key is optional — without it, brief generation runs on the anonymous per-IP tier. Get a free key (8 briefs/month) at casemargin.com/signup. The escalation readiness check is free and needs no key. Drop the whole env block to run keyless.

Also on the MCP Registry as com.casemargin/casemargin-mcp-server, and on npm.

Running from source

Only needed if you're modifying the server:

git clone https://github.com/Casemargin/casemargin-mcp-server.git
cd casemargin-mcp-server
npm install
npm run build

Then point command at node and args at the absolute path of the built dist/index.js.

Example usage

"What's happening with this ticket?"

Paste a ticket thread into your AI client and ask what's going on:

You: 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 is on the Premium SLA, CFO is affected. Told them we'd escalate if not fixed by Friday…

Claude calls generate_case_brief and returns a structured brief:

Quick scan — Recurring VPN disconnects tied to a 30-minute DHCP lease renewal on a Premium SLA account with an executive affected; moderate-to-high urgency. Next step: Extend the DHCP lease time on the affected scope and confirm whether the drops track lease renewals. Status: Actively being worked.

…plus the full breakdown of current problem, actions already taken (each with outcome), and key context.

"Is this ticket ready to escalate?"

You: Is this ticket ready to escalate to L2?

(pastes the same thread)

Claude calls check_escalation_readiness and returns the score with a breakdown:

62/100 — borderline. Problem clarity is strong (80), but troubleshooting evidence is thin (55) — no packet capture or client logs attached — and business impact is asserted, not quantified (40). Before escalating, L2 will ask: "What do the VPN client logs show at the moment of the drop?" and "Does the issue follow the user across networks?"

Security and privacy

The server makes network calls and reads environment variables, so supply-chain scanners flag both. SECURITY.md documents the full extent: one outbound origin, two environment variables, and no filesystem, subprocess, dynamic-code, install-script, or telemetry access at all.

Two things worth knowing up front. Only the ticket_content you pass to a tool leaves your machine — nothing else is collected, and raw ticket text is never stored server-side. And because the API key travels as a request header, the server refuses to start if CASEMARGIN_API_URL points at a non-https origin other than loopback, rather than silently sending your key in cleartext.

Releases are published from GitHub Actions with npm provenance, so you can verify the tarball came from this repository:

npm audit signatures

About CaseMargin

CaseMargin turns raw support tickets into structured case briefs so the next agent picks up cold in seconds, not minutes. The web app, Zendesk integration, and free Escalation Readiness Score tool live at casemargin.com.

Available Tools

2 tools
check_escalation_readinessCheck escalation readinessA

Analyze whether a support ticket is ready to escalate to L2. Returns a readiness score (0-100), dimensional breakdown, predicted L2 questions, and missing items.

ParametersJSON Schema
NameRequiredDescriptionDefault
ticket_contentYesThe support ticket notes to evaluate for L2 escalation readiness

Output Schema

ParametersJSON Schema
NameRequiredDescription
readinessYes
dimensionsYes
missing_itemsYes
overall_scoreYes
predicted_l2_questionsYes

TDQS

A4/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden of behavioral disclosure. It indicates the tool analyzes input and returns specific outputs (score, breakdown, questions, missing items), implying read-only behavior, but it does not explicitly state it is non-destructive or describe limitations/auth requirements.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences, front-loaded with the purpose, and includes valuable return-value details without any fluff. Every sentence earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple tool with one parameter and an output schema, the description covers the main purpose and outputs (readiness score, breakdown, questions, missing items). It slightly lacks explicit safety context, but the schema and clear purpose make it nearly complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The single parameter ticket_content is fully described in the schema with 100% coverage, so the tool description does not need to add parameter semantics. The baseline of 3 applies since the schema already provides complete parameter meaning.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('Analyze whether a support ticket is ready to escalate to L2') and the resource (support ticket), making the tool's purpose explicit. It distinguishes from the sibling tool generate_case_brief by focusing on readiness assessment rather than brief generation.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides a clear context for when to use the tool: evaluating a ticket for L2 escalation readiness. However, it does not explicitly mention when not to use it or name alternatives, so it lacks explicit exclusions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

generate_case_briefGenerate case briefA

Generate a structured case brief from a support ticket thread. Returns an assessment, what has been tried, current status, and recommended next step.

ParametersJSON Schema
NameRequiredDescriptionDefault
ticket_contentYesThe full support ticket thread — customer messages, agent replies, internal notes

Output Schema

ParametersJSON Schema
NameRequiredDescription
metadataYes
full_briefYes
quick_scanYes

TDQS

A4.1/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the transparency burden. It discloses what the tool returns ('assessment, what has been tried, current status, and recommended next step') and that the brief is structured, which are meaningful behavioral details. It does not mention side effects or prerequisites, but for a generation tool, this is adequate.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, front-loaded sentence that states the action and outcome. Every word earns its place, with no redundancy or filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity (one parameter, full schema coverage, and an output schema), the description is complete. It specifies the input source and the output structure, covering the essential information an agent needs to invoke and interpret results.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema description covers the 'ticket_content' parameter 100%, explaining it as the full support ticket thread with examples. The tool description merely reiterates 'from a support ticket thread' without adding new format or usage details, so it meets the baseline but does not exceed it.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb ('Generate') and resource ('structured case brief') from a support ticket thread, clearly stating its function. It also lists the output components, distinguishing it from the sibling tool 'check_escalation_readiness'.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage when a case brief from a ticket thread is needed, but provides no explicit 'when to use' or 'when not to use' guidance. It does not reference or differentiate from the sibling tool 'check_escalation_readiness', leaving usage context to inference.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 2 tool updatesv1.0.0
    • First observedcheck_escalation_readiness
    • First observedgenerate_case_brief
Deploy Server
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A4.1/5.0

Scored across 2 tools

Disambiguation5/5

Both tools operate on support tickets but have clearly distinct purposes: one generates a structured brief, the other assesses escalation readiness. No overlap or ambiguity in their output.

Naming Consistency5/5

Both tool names follow a consistent verb_noun pattern with underscores, making the toolset predictable and easy to navigate.

Tool Count3/5

With only two tools, the server feels thin for the apparent domain, but each tool serves a specific analytic function, making it a borderline case.

Completeness3/5

The two tools cover the workflow of briefing and escalation readiness, but lack any case management operations (e.g., list, update, delete), leaving notable gaps in the domain surface.

Maintenance

ActivitySlowing
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers

  • relay

    future-beat
    A
    license
    Not graded
    quality
    B
    maintenance
    Enables MCP clients to drive Relay, an AI support-triage agent, by exposing tools for customer lookup, documentation search, ticket classification, reply, and escalation, with full guardrails and read-only mode option.
    MIT

  • support-agent-mcp

    Kartz82
    A
    license
    Not graded
    quality
    B
    maintenance
    Exposes order status lookup and knowledge base search tools from the Support Agent AI over MCP, enabling MCP clients to handle customer support queries with grounded, citation-backed answers.
    MIT

  • ParcelPilot MCP Server

    PraneethGoud04
    F
    license
    Not graded
    quality
    C
    maintenance
    Enables AI agents to retrieve customer, order, ticket, policy, and agreement information, and to prepare or execute state-changing support actions like escalations and follow-ups with confirmation and access control.
    -