CMR Client Health

Python 3.10+ License: MIT

An MCP server that gives Client Success teams an instant, natural-language health read on any client account — modeled on Rustici Content Controller's reporting layer.

Ask a question like "How is BioPharma Inc. doing ahead of their renewal?" in any MCP client (Claude Desktop today, a Slack bot tomorrow) and get back the courses that are underperforming, whether their content is current, and how they receive content — without anyone pulling and reading a report by hand.

---

The problem

CMR Institute produces SME-vetted life-sciences training and distributes it to pharma / medical-device clients through Rustici Content Controller. Roughly 40% of those clients have no LMS of their own — they consume content through Content Controller Launcher links. For those accounts, CMR is the only party that can see learner engagement.

That engagement data lives in reports someone has to pull and read manually. Renewal risk — a course nobody is finishing, compliance content that has gone stale — hides in that data until it's a renewal conversation. This server surfaces it conversationally instead.

What it does

Three tools, reachable in natural language from any MCP client:

Tool	Answers
get_client_health(account_id)	"How is this client doing overall?" — per-course completion, scores, content freshness, delivery method, renewal date, plus a computed summary.
get_lowest_performing_courses(account_id, limit=3)	"Where is the renewal risk?" — worst-completion courses with a one-line risk note each.
get_launcher_clients()	"Which accounts have no LMS, so we're their only visibility?" — the highest monitoring priority.

Build the tools once; every MCP client reuses them.

Beyond tools — the full MCP surface

Most MCP servers stop at tools. This one implements all three MCP primitives, because a real CSM workflow needs more than model-triggered actions:

Primitive	Name	What it's for
Resource (app-controlled context)	clients://directory	A read-only roster of every account — id, name, delivery method, renewal date, course count. The host app can attach it up front so the model knows the valid, correctly-spelled account names without spending a tool round-trip.
Prompt (user-invokable template)	renewal_health_briefing(account)	The CSM's standard pre-renewal review, packaged as a reusable, parameterized template (it shows up as a named command in the client). It orchestrates all three tools into one repeatable play, so anyone on the team runs the whole briefing by name instead of remembering the question sequence.

• Tools are model-controlled — the LLM decides when to call them.
• Resources are app-controlled — read-only context the host attaches.
• Prompts are user-controlled — named templates a person triggers.

Architecture

  ┌─────────────────────┐   stdio    ┌──────────────────┐         ┌────────────────────────────┐
  │  MCP Client          │ <───────>  │  FastMCP server  │ <────>  │  mock data                 │
  │  (Claude Desktop)    │  (JSON-RPC │  (server.py)     │         │  (models Content           │
  │                      │  subprocess)│  3 tools         │         │   Controller               │
  │                      │            │  + 1 resource    │         │   usage/LearnerHistory)    │
  │                      │            │  + 1 prompt      │         │                            │
  └─────────────────────┘            └──────────────────┘         └────────────────────────────┘

The mock-data lookup is the only thing that's fake. Swapping it for a real Content Controller integration means changing one function body per tool — replace the JSON lookup with an authenticated automation-API call. The tool contract (names, arguments, docstrings — the part the LLM sees and reasons about) stays identical, so nothing downstream has to change.

The post-parse note

This is the reporting / analytics layer. It sits downstream of SCORM/xAPI parsing. Pulling structured course data out of raw content packages is a separate, hard problem that Rustici Generator solves; this server consumes the already-structured, post-parse reporting data. It deliberately makes no claim to parse SCORM itself.

What's real vs. modeled in the data

The credibility win is in naming the boundary, not blurring it:

• Real (from Rustici Content Controller v4.1 release notes): the endpoint names (usage/LearnerHistory, usage/RegistrationHistory, usage/InteractionHistory), the convention of string IDs, and the CourseVersion concept.
• Modeled / approximate: the exact field shape of data/mock_data.json. It's a reasonable approximation of the live response, not a verified copy. In production these fields would be mapped against the actual automation-API output.

---

Setup

Requires Python 3.10+ and uv (falls back to pip).

# from the project directory
uv run server.py        # starts the server over stdio (Ctrl-C to stop)
uv run test_local.py    # runs the local smoke test for all three tools

Don't have uv? pip install "fastmcp>=3.4,<4" then python server.py.

Install into Claude Desktop

Primary (recommended) — let FastMCP write the config. Lowest-risk; try this first. It auto-detects the Claude Desktop config location and writes the entry (expects Claude Desktop in its default install location):

fastmcp install claude-desktop server.py

Fallback — manual config. Use this if the CLI can't find the config or Claude Desktop is installed somewhere non-standard. Edit claude_desktop_config.json in this repo, replace the path with your absolute project path, and paste it into Claude Desktop's config file. The --with fastmcp flag isolates the dependency so a missing global install can't break the launch:

{
  "mcpServers": {
    "cmr-client-health": {
      "command": "uv",
      "args": ["run", "--with", "fastmcp", "--directory",
               "/ABSOLUTE/PATH/TO/cmr-client-health-mcp", "fastmcp", "run", "server.py"]
    }
  }
}

Claude Desktop's config file lives at:

• macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
• Windows: %APPDATA%\Claude\claude_desktop_config.json

Gotchas that silently break it:

• The --directory path must be absolute — relative paths fail in Claude Desktop.
• Validate the JSON — a single trailing comma silently breaks the whole config.
• Fully quit and reopen Claude Desktop after editing — closing the window is not enough; the config is only read on a cold start.
• Verify the server appears under the Developer tab / the tools (🔌) icon before relying on it.

Demo prompt

Paste this into Claude Desktop once the server is connected:

"BioPharma Inc.'s renewal is coming up. Give me a health read — which courses are underperforming, is their content current, and are they on Launcher or their own LMS? Then draft a short check-in note I can send their Client Success Manager."

Claude will call get_client_health and get_lowest_performing_courses, see the two seeded problem courses (a ~38%-completion Pharmacovigilance course and a stale GxP Compliance course), note that BioPharma is on Launcher (so CMR is their only visibility), and draft the note.

Roadmap / "in production"

• Swap mock for the live automation API — replace each tool's data lookup with an authenticated (Bearer-token) Content Controller call; the tool contract is unchanged.
• get_content_freshness — a freshness view across all clients, not just one.
• Streamable HTTP transport + auth — so a shared team Slack bot can hit one server instead of every CSM running a local copy.
• Layer Rustici Generator's parsed JSON — for content-level Q&A on top of the engagement reporting.

Disclaimer

Built on mock data shaped to mirror Content Controller's reporting schema. It is not affiliated with, nor connected to, any live CMR Institute or Rustici system, and exposes no real customer data.