CMR Client Health
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
| logging | {} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| extensions | {
"io.modelcontextprotocol/ui": {}
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| get_client_healthA | 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. |
| get_lowest_performing_coursesA | 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. |
| get_launcher_clientsA | 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. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
| renewal_health_briefing | Generate a complete pre-renewal health briefing for one client account. |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
| client_directory | The full roster of client accounts: id, name, delivery method, renewal date, and course count. Read-only reference context for any client-health workflow. |
TDQS
Scored across 3 tools
Each 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.