What can you do with this server?

It connects AI assistants to On-Call Health on-call burnout data, and in this configuration runs in Code Mode where three meta-tools expose the full analytics catalog. * Discover tools with search — query the catalog by keyword, with optional tag filters, limits, and brief/detailed/full detail levels. * Inspect schemas with get_schema — fetch parameter schemas for specific tools before calling them. * Chain calls with execute — run sandboxed async Python using await call_tool(name, params) to combine multiple tool calls and return one final result, saving context on multi-step tasks. * Underlying catalog (reachable through the meta-tools): validate integrations; list Rootly, GitHub, Slack, Jira and Linear integrations; see who is currently on call. * Run new burnout analyses (analysis_run, analysis_start/analysis_status) or read the latest one (analysis_current, analysis_summary, analysis_results). * Query member-level risk: at-risk members, safe responders who can take extra shifts, risk checks for specific Rootly user IDs, and day-by-day health for one member. * Access methodology and analysis metadata via MCP resources, and use weekly_brief / investigate_responder prompts for guided reports. * Scores run 0–100 (higher = more at risk) and inform staffing decisions, not medical diagnosis.

Which integrations are available for this server?

Provides access to on-call health analysis for data from GitHub. Provides access to on-call health analysis for data from Jira. Provides access to on-call health analysis for data from Linear. Provides access to on-call health analysis for data from Slack.

How do I use oncallhealth-mcp?

1. Click on "Deploy Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@oncallhealth-mcp start a new burnout analysis for the last 30 days" 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.

oncallhealth-mcp

Official

by Rootly-AI-Labs

Overview Schema Source Related Servers Discussions(1)Admin

Python

Remote

oncallhealth-mcp

PyPI version Python 3.10+

MCP server for On-Call Health burnout analysis. Connects AI assistants to your on-call data for workload insights.

Prerequisites

An On-Call Health account at oncallhealth.ai
An API key from oncallhealth.ai/settings/api-keys

Related MCP server: whoop-mcp-server

Installation

The server runs locally over stdio with uvx (no install step) and reads the API key from the ONCALLHEALTH_API_KEY environment variable. Pick your client:

Claude Code

claude mcp add oncallhealth --env ONCALLHEALTH_API_KEY=och_live_... -- uvx oncallhealth-mcp

Claude Desktop

Add to claude_desktop_config.json (macOS: ~/Library/Application Support/Claude/claude_desktop_config.json, Windows: %APPDATA%\Claude\claude_desktop_config.json):

{
  "mcpServers": {
    "oncallhealth": {
      "command": "uvx",
      "args": ["oncallhealth-mcp"],
      "env": { "ONCALLHEALTH_API_KEY": "och_live_your_api_key_here" }
    }
  }
}

Cursor

Add to .cursor/mcp.json in your project (or ~/.cursor/mcp.json for global):

{
  "mcpServers": {
    "oncallhealth": {
      "command": "uvx",
      "args": ["oncallhealth-mcp"],
      "env": { "ONCALLHEALTH_API_KEY": "och_live_your_api_key_here" }
    }
  }
}

VS Code / GitHub Copilot

Add to .vscode/mcp.json in your project:

{
  "servers": {
    "oncallhealth": {
      "command": "uvx",
      "args": ["oncallhealth-mcp"],
      "env": { "ONCALLHEALTH_API_KEY": "och_live_your_api_key_here" }
    }
  }
}

Windsurf

Add to ~/.codeium/windsurf/mcp_config.json:

{
  "mcpServers": {
    "oncallhealth": {
      "command": "uvx",
      "args": ["oncallhealth-mcp"],
      "env": { "ONCALLHEALTH_API_KEY": "och_live_your_api_key_here" }
    }
  }
}

Codex CLI

codex mcp add oncallhealth --env ONCALLHEALTH_API_KEY=och_live_... -- uvx oncallhealth-mcp

Gemini CLI

gemini mcp add oncallhealth -e ONCALLHEALTH_API_KEY=och_live_... uvx oncallhealth-mcp

Manual / other clients

pip install oncallhealth-mcp
export ONCALLHEALTH_API_KEY=och_live_...
oncallhealth-mcp

Or run without installing: ONCALLHEALTH_API_KEY=och_live_... uvx oncallhealth-mcp.

Configuration

Variable	Required	Default	Description
`ONCALLHEALTH_API_KEY`	Yes (stdio)	-	API key from oncallhealth.ai
`ONCALLHEALTH_API_URL`	No	`https://api.oncallhealth.ai`	API endpoint URL
`ONCALLHEALTH_CODE_MODE`	No	off	`1` exposes the catalog through Code Mode meta-tools (see below)
`ONCALLHEALTH_POLL_INTERVAL`	No	`5.0`	Seconds between status checks inside `analysis_run` (backs off to `ONCALLHEALTH_POLL_MAX_INTERVAL`, default `30.0`)
`ONCALLHEALTH_MCP_ALLOWED_HOSTS`	No	-	HTTP only: comma-separated host names that enable the Host/Origin DNS-rebinding guard

Request timeouts, retries and circuit-breaker settings are also configurable; see oncallhealth_mcp/client/config.py.

Security note

Avoid committing API keys to version control. Use environment variables or a secrets manager instead of hardcoding keys in config files.

Protocol compatibility

The server implements MCP revision 2026-07-28 (stateless Streamable HTTP, Mcp-Method/Mcp-Name routing headers, cacheable list results, the Tasks extension) and negotiates older revisions per connection, so clients on the 2025 handshake-era protocol keep working. Every tool publishes annotations (read-only, idempotent, open-world) and a structured output schema. The deprecated HTTP+SSE transport is not served.

Tools

Start with validate_integrations, then analysis_current (or analysis_run for a fresh analysis), then analysis_summary and the member-level tools.

Tool	What it does
`validate_integrations`	Check that every connected integration has valid credentials. `force_refresh` bypasses the backend cache.
`integrations_list`	List connected Rootly, GitHub, Slack, Jira and Linear integrations.
`oncall_users`	Who is currently on call for a Rootly integration (`integration_id`).
`analysis_current`	Metadata of the most recent analysis (status, timestamps, config).
`analysis_run`	Start an analysis and wait for it: `days_back` (default 30), `include_weekends`, `integration_id`, `wait_timeout_seconds` (default 600). Returns the team summary. Runs as a background task for clients that support the MCP Tasks extension, inline otherwise, with progress messages while waiting.
`analysis_start`	Start an analysis without waiting. Poll with `analysis_status`.
`analysis_status`	Status and metadata of an analysis (`analysis_id`).
`analysis_summary`	Team averages, risk distribution, top five at-risk and healthiest members.
`analysis_results`	Full raw payload of a completed analysis (large; prefer the focused tools).
`get_at_risk_users`	Members at or above `min_och_score` (default 50) in `include_risk_levels` (default `["medium", "high"]`), with Rootly/PagerDuty/Slack/GitHub IDs.
`get_safe_responders`	Members at or below `max_och_score` (default 30) who could take extra shifts, up to `limit`.
`check_users_risk`	Risk check for specific `rootly_user_ids` (list of integers), split into at-risk, healthy and not-found.
`member_daily_health`	Day-by-day health, incident and after-hours breakdown for `member_email`.

OCH scores run 0-100; higher means more at risk. Scores inform staffing decisions and are not a medical diagnosis.

Resources

URI	Content
`oncallhealth://methodology`	Short description of the scoring methodology
`oncallhealth://analyses/latest`	Metadata of the most recent analysis (JSON)
`oncallhealth://analyses/{analysis_id}/summary`	Team summary of a completed analysis (JSON)

Prompts

Prompt	Arguments	Purpose
`weekly_brief`	`team_name`	Weekly on-call health brief with follow-up actions
`investigate_responder`	`member_email`, `analysis_id`	Dig into one responder's trend and recommend shift changes

Code Mode (optional)

With --code-mode or ONCALLHEALTH_CODE_MODE=1 the catalog is exposed through FastMCP Code Mode: three meta-tools (search, get_schema, execute) let an agent discover tools on demand and chain calls in a sandboxed Python snippet. It saves context when an agent needs many calls per task, at the cost of hiding the tool list, annotations and output schemas from clients that read them directly. Off by default.

CLI reference

usage: oncallhealth-mcp [-h] [--transport {stdio,http}] [--host HOST]
                        [--port PORT] [--code-mode] [-v] [--version]

options:
  --transport {stdio,http}  Transport to use (default: stdio)
  --host HOST               Host to bind to (http transport only, default: 127.0.0.1)
  --port PORT               Port to bind to (http transport only, default: 8000)
  --code-mode               Expose the catalog through Code Mode meta-tools
  -v, --verbose             Enable verbose logging
  --version                 show program's version number and exit

Hosted deployment (Streamable HTTP)

oncallhealth-mcp --transport http (or the Docker image, which runs uvicorn oncallhealth_mcp.transport:mcp_http_app) serves:

POST /mcp: stateless Streamable HTTP MCP endpoint
GET /health: unauthenticated health check

Every MCP request must carry the user's API key as Authorization: Bearer och_...; X-API-Key: och_... is accepted as well. Keys are verified against the On-Call Health API (successful checks are cached for five minutes) and unauthenticated requests get 401 before any tool runs. Tool calls are rate limited per key and per tool (for example analysis_run and analysis_start at 5/minute) identified from the JSON-RPC body, with 429 and Retry-After on excess.

Example remote client configuration (Claude Code):

claude mcp add --transport http oncallhealth https://your-host/mcp --header "Authorization: Bearer och_live_..."

Because the server is stateless you can run several uvicorn workers or replicas. For analysis_run background tasks to be shared across workers, point FastMCP's task backend at Redis or Valkey with FASTMCP_DOCKET_URL; the default in-memory backend is per process.

Set ONCALLHEALTH_MCP_ALLOWED_HOSTS=mcp.example.com to enable FastMCP's Host/Origin DNS-rebinding guard for the public host name.

docker build -t oncallhealth-mcp .
docker run -p 8080:8080 oncallhealth-mcp

License

Apache-2.0

Available Tools

3 tools

executeB

Chain await call_tool(...) calls in one Python block; prefer returning the final answer from a single block. Use return to produce output. Only call_tool(tool_name: str, params: dict) -> Any is available in scope.

Name	Required	Description	Default
`code`	Yes	Python async code to execute tool calls via call_tool(name, arguments)

TDQS

B3.4/5.0

Behavior2/5

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

With no annotations provided, the description must fully disclose behavior. It mentions that only `call_tool` is available and that `return` produces output, but it omits critical details like execution environment, side effects, timeout, error handling, and security restrictions.

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 three concise sentences with no extraneous content, front-loaded with the core purpose, and every sentence adds value.

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

Completeness2/5

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

Despite low complexity (one parameter), the description is insufficient for safe usage of arbitrary code execution. It lacks details on output handling, variable scope, error propagation, and security constraints, making it incomplete for an agent to reliably invoke this tool.

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?

Schema coverage is 100%, so baseline is 3. The description adds minimal value by detailing the `call_tool` signature and return usage, but it essentially repeats the schema's code description.

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 explicitly states that the tool executes Python code to chain asynchronous tool calls via the `call_tool` function, distinguishing it from siblings like `get_schema` and `search` which are for single operations or queries.

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 advises to 'prefer returning the final answer from a single block' implying a pattern, but it does not explicitly state when to use this tool versus making individual calls or using alternatives, nor does it provide exclusion criteria.

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

get_schemaA

Get parameter schemas for specific tools.

Use after searching to get the detail needed to call a tool.

Name	Required	Description	Default
`tools`	Yes	List of tool names to get schemas for
`detail`	No	'brief' for names and descriptions, 'detailed' for parameter schemas as markdown, 'full' for complete JSON schemas	detailed

Output Schema

Name	Required	Description
`result`	Yes

TDQS

A3.8/5.0

Behavior2/5

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

No annotations provided, and the description does not disclose any behavioral traits such as side effects, authorization needs, or rate limits. For a read-only tool, the description could mention that it is non-destructive, but it remains silent.

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?

Two sentences, no wasted words. Essential information is front-loaded.

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?

Tool is simple, output schema exists, so description doesn't need to explain return values. The description covers the essential usage flow, but slight improvement could mention that it returns JSON schemas.

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?

Schema coverage is 100%, so baseline is 3. Description adds context about using after searching, which helps understand the purpose of the 'tools' parameter, but doesn't add extra meaning beyond the schema.

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?

Description clearly states the tool gets parameter schemas for specific tools. Verb 'get' and resource 'parameter schemas for specific tools' are specific and distinct from sibling tools like execute, search, and tags.

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?

Explicitly states 'Use after searching to get the detail needed to call a tool.' This gives clear context for when to use it, though it doesn't 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.

searchA

Search for available tools by query.

Returns matching tools ranked by relevance.

Name	Required	Description	Default
`query`	Yes	Search query to find available tools
`tags`	No	Filter to tools with any of these tags before searching
`detail`	No	'brief' for names and descriptions, 'detailed' for parameter schemas as markdown, 'full' for complete JSON schemas	brief
`limit`	No	Maximum number of results to return

Output Schema

Name	Required	Description
`result`	Yes

TDQS

A4/5.0

Behavior3/5

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

No annotations provided, so description carries full burden. It mentions 'ranked by relevance' but lacks details on read-only nature, authentication, or limits. Basic transparency, but not rich.

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?

Two sentences, directly states purpose and output. No wasted words; front-loaded with key information.

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?

Given the output schema exists and sibling tools are few, the description is adequate but could clarify what 'available tools' refers to (e.g., tools in this service).

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?

Schema coverage is 100%, baseline 3. The description adds no extra meaning beyond the schema's parameter descriptions (e.g., query, tags, detail, limit).

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 'Search for available tools by query' with a specific verb and resource. It distinguishes well from sibling tools (execute, get_schema) which have different purposes.

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?

No explicit when-to-use or when-not-to-use guidance, but the context of sibling tools implies search is for discovery, not execution or schema retrieval.

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.

3 tool updatesv0.3.0May 26, 2026
- First observedexecute
- First observedget_schema
- First observedsearch

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

B3.4/5.0

Scored 2026-05-26 17:35 across 3 tools

Disambiguation5/5

Each tool has a clearly distinct purpose: execute chains calls, get_schema retrieves parameter details, and search finds tools. There is no overlap or ambiguity.

Naming Consistency4/5

Tool names are imperative verbs (execute, search) and one uses get_ prefix (get_schema). While mostly consistent, the underscore in get_schema differs from the others, causing a minor deviation.

Tool Count2/5

With only 3 tools, the server feels underdeveloped for the domain implied by 'oncallhealth'. The tools are generic meta-tools rather than domain-specific actions, making the count too low for its apparent scope.

Completeness1/5

The tool set is severely incomplete for an oncall health server. It lacks any domain-specific tools (e.g., managing incidents, schedules, alerts) and only provides generic utility functions, failing to cover the intended domain.

Maintenance

ActivityNo data

ResponsivenessSyncing

Resources

Related MCP Connectors

OneSchema MCP Server
co.oneschema
MCP server that lets AI assistants use all OneSchema features exposed via the public API.
Data Platforms App Automation
1
https://api.oneschema.co/mcp
uptrack-mcp
io.github.Uptrack-App
MCP server for Uptrack uptime monitoring. Manage monitors and incidents from AI agents.
Monitoring Observability
1
https://api.uptrack.app/mcp
Cliniko MCP by usefulapiA
io.usefulapi
Hosted MCP server for Cliniko — patients, appointments, availability, and invoices for AI agents.
Biology & Medicine Calendar Management CRM
2
https://cliniko.usefulapi.io/mcp
Sentry
io.github.getsentry
MCP server for Sentry - error monitoring, issue tracking, and debugging for AI assistants
Monitoring Observability
1958
https://mcp.sentry.dev/mcp

Related MCP Servers

whoop-ai-mcp
Health & Wellness Fitness Tracking
shashankswe2020-ux
A
license
Not graded
quality
B
maintenance
MCP server that connects AI assistants like Claude to WHOOP health data, enabling natural language queries about recovery, sleep, workouts, and more.
Updated 2 days ago (2026-11-06 14:14 UTC)
291 npm
177
MIT
whoop-mcp-server
Health & Wellness Fitness Tracking
benhursenabathi
A
license
A
quality
D
maintenance
MCP server that enables AI assistants to access Whoop health data including recovery, sleep, workouts, and daily strain for personalized health recommendations.
Updated 10 months ago (2025-12-27 15:26 UTC)
7
20 npm
MIT
oura-mcp
Health & Wellness Fitness Tracking
johnie
F
license
Not graded
quality
D
maintenance
An MCP server that enables AI assistants to access Oura Ring health data including activity, sleep, heart rate, stress, and personal info.
Updated 9 months ago (2026-02-10 15:18 UTC)
20 npm
2
-
Google Health ChatGPT MCP
Health & Wellness Biology & Medicine
RoyLaw
F
license
Not graded
quality
D
maintenance
Self-hosted MCP server that provides read-only access to Google Health API v4, enabling analysis of personal health data via OpenAI Responses API or ChatGPT.
Updated 3 months ago (2026-08-03 01:24 UTC)
-

oncallhealth-mcp

Prerequisites

Installation

Claude Code

Claude Desktop

Cursor

VS Code / GitHub Copilot

Windsurf

Codex CLI

Gemini CLI

Manual / other clients

Configuration

Security note

Protocol compatibility

Tools

Resources

Prompts

Code Mode (optional)

CLI reference

Hosted deployment (Streamable HTTP)

Links

License

Available Tools

Output Schema

Output Schema

Tool Schema Changelog

Maintenance

Resources

Related MCP Connectors

Related MCP Servers