Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@CMR Client Health How is BioPharma Inc. doing ahead of their renewal?"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
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.
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.
Related MCP server: Vitally MCP Server
Three tools, reachable in natural language from any MCP client:
Tool | Answers |
| "How is this client doing overall?" — per-course completion, scores, content freshness, delivery method, renewal date, plus a computed summary. |
| "Where is the renewal risk?" — worst-completion courses with a one-line risk note each. |
| "Which accounts have no LMS, so we're their only visibility?" — the highest monitoring priority. |
Build the tools once; every MCP client reuses them.
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) |
| 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) |
| 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.
┌─────────────────────┐ 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.
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.
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.
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 toolsDon't have
uv?pip install "fastmcp>=3.4,<4"thenpython server.py.
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.pyFallback — 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.
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.
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.
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.
Return a full learning-engagement health snapshot for a single client account, modeled on Content Controller's usage/LearnerHistory report. Includes per-course completion rates, average scores, content freshness (last update date), the client's delivery method (Launcher vs. their own LMS), and contract renewal date.
Use this when someone asks how a specific client is doing, wants a health check before a renewal, or needs an overview of a client's engagement.
| Name | Required | Description | Default |
|---|---|---|---|
| account_id | Yes | The client account ID (e.g. 'acct-001'). Case-insensitive match also accepted on account_name for convenience. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It explains the tool returns a health snapshot modeled on a specific report and lists included fields. However, it does not disclose potential behavior like error handling, performance constraints, or whether it is a read-only operation, leaving some gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the purpose and usage. Every word adds value, with no redundant or irrelevant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity (one parameter, no nested objects, and an output schema exists), the description is complete. It covers what the tool does, when to use it, and enough context for an agent to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage for the single parameter, with a clear description including example and case-insensitivity. The tool description does not add additional meaning beyond the schema, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns a 'full learning-engagement health snapshot' for a single client account, listing specific data points like per-course completion rates, average scores, content freshness, delivery method, and contract renewal date. This distinguishes it from siblings like get_launcher_clients and get_lowest_performing_courses.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Use this when someone asks how a specific client is doing, wants a health check before a renewal, or needs an overview of a client's engagement.' This provides clear guidance on when to use the tool, though it does not mention when not to use or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return all clients delivered via Content Controller Launcher (i.e. clients with NO LMS of their own). For these clients, CMR is the only party with visibility into learner engagement — so proactive monitoring matters most here. Use this to identify which accounts need CMR-side engagement monitoring.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It states the tool returns all such clients, implying a read operation with no side effects. However, it does not disclose behavioral details such as performance implications, ordering, or error conditions. The description adds context but lacks deeper behavioral transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loading the purpose. It is efficient with no extraneous words, providing maximum information in minimal space.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters and an output schema exists, the description covers the necessary context: what is returned (launcher clients), why it matters (proactive monitoring), and how to use it (identify accounts needing engagement monitoring). It is fully complete for this simple tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has zero parameters with 100% coverage. The description adds meaning by explaining the concept of 'launcher clients' and the importance of monitoring, which goes beyond the empty schema. Baseline is 3 due to high coverage, but the added context justifies a 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns 'all clients delivered via Content Controller Launcher (i.e. clients with NO LMS of their own)'. This is a specific verb+resource, and it distinguishes from sibling tools (get_client_health, get_lowest_performing_courses) by focusing on a different subset and use case.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Use this to identify which accounts need CMR-side engagement monitoring', providing a clear use case. It also explains the context of proactive monitoring. However, it does not mention when not to use it or compare to siblings explicitly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return the lowest-completion courses for a client, sorted ascending by completion rate. Use this to surface renewal risk: low completion means the client isn't getting value from the content, which threatens contract renewal.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | How many of the worst-performing courses to return (default 3). | |
| account_id | Yes | The client account ID or name. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses sort order and business intent, but omits details about output format, error handling (e.g., invalid account_id), or response structure. Although there is an output schema, its existence is not mentioned, and the description does not elaborate on what fields are returned.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description consists of two tightly written sentences. The first delivers the core functionality, the second adds usage context. No redundant or extraneous information is present.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple retrieval tool with an output schema, the description covers purpose, usage context, and behavioral sort order. It does not describe output structure, but that is acceptable since the output schema exists and the description need not repeat it. Minor gap: no mention of limit default (though present in schema).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with each parameter having a clear schema description. The tool description adds business context but no additional semantic detail beyond what the schema provides. Baseline 3 applies as the description does not enhance parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns lowest-completion courses for a client sorted ascending by completion rate. It distinguishes itself from siblings like get_client_health and get_launcher_clients by focusing on renewal risk through course completion data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly suggests using this tool to surface renewal risk, providing a clear business context. While it does not compare with siblings or mention when not to use, the guidance is specific and actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.1.0get_client_healthget_launcher_clientsget_lowest_performing_coursesEach tool targets a distinct aspect: overall health snapshot, listing launcher clients, and lowest performing courses. No overlap in purpose.
All tools follow a consistent 'get_' prefix followed by descriptive noun phrases, e.g., get_client_health, get_launcher_clients.
3 tools is on the low end but well-scoped for a focused health monitoring server. No superfluous tools.
Covers the key health monitoring needs: overall snapshot, identification of high-risk launcher clients, and renewal risk via course performance. Minor gaps like historical trends or per-user data are acceptable.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Read-only account intelligence for Customer Success and Account Management teams.
Your AI copilot for customer onboarding — projects, KPIs, tasks, and safe writes.
Conversational access to advertising performance data, creative analysis, and campaign insights
Conversational access to advertising performance data, creative analysis, and campaign insights
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/RahulModugula/cmr-client-health-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
