oncall-router-mcp
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., "@oncall-router-mcpwho owns the api-gateway service?"
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.
oncall-router-mcp
An MCP server that answers the three questions that eat the first ten minutes of an incident: who owns this, who do I wake and by when, and what does the runbook say to try first. Plus a fourth that most tools get wrong, which is where should we be on the clock right now, measured from when impact started rather than from when somebody opened a ticket.
No runtime dependencies, no API key, no network calls, no telemetry. It reads one local file. pytest is needed only to run the gates.
Why this exists
Escalation knowledge lives in three places: a wiki nobody updated, a rotation tool that only knows the current shift, and the head of whoever has been there longest. At 2am the expensive minutes go to working out who to call, not to fixing anything.
This puts that knowledge somewhere an assistant can reach it, and makes the timing explicit. The design opinion in the code is that escalation timing runs from impact start. A ticket opened twenty minutes late does not buy the responder twenty extra minutes, and a tool that measures from ticket creation will quietly tell you that it does.
Related MCP server: runframe-mcp-server
The four tools
tool | answers | when it cannot |
| which team owns a service, and how to reach them now | says so, and offers near matches as candidates rather than as an answer |
| who to wake, in order, with the minute each hop is due | refuses an unknown severity rather than defaulting to the quietest one |
| what the runbook says to check first | falls back to the service's general steps and sets |
| which hop should be active now, and what is overdue | requires an explicit |
Every tool fails closed. A near miss never silently resolves, because a confident wrong escalation costs more than an honest "I do not know".
See docs/TRANSCRIPT.md for real output from every tool, including the failure paths. CI regenerates that file and fails the build if it drifts from what the code actually produces.
Run it
git clone <this repo> && cd oncall-router-mcp
python -m pip install "pytest>=7" # the only dependency, and only to run the tests
python -m pytest tests/ -q # 40 tests
PYTHONPATH=src python -m oncall_router.server --catalog catalog.tomlTo wire it into Claude Desktop or Claude Code, add this to your MCP client config, using absolute paths:
{
"mcpServers": {
"oncall-router": {
"command": "python",
"args": ["-m", "oncall_router.server", "--catalog", "/abs/path/to/catalog.toml"],
"env": { "PYTHONPATH": "/abs/path/to/oncall-router-mcp/src" }
}
}
}Point an MCP client at that command. To use your own data, copy catalog.toml, edit it,
and pass --catalog yours.toml. No code changes: the catalog is data, and a test proves
it by running the same tool against two different catalogs.
The catalog
One TOML file holding services, the team that owns each, escalation chains with timings,
and runbook steps by symptom. TOML rather than YAML because tomllib ships in the Python
standard library, so the catalog costs this project zero dependencies.
Aliases matter more than they look. During an incident people type the name they remember,
so gateway, apigw, edge and the gateway all resolve to api-gateway.
What this deliberately does not do
No live integrations. It does not read your incident tool, your rotation tool, or your monitoring. Those are per-customer decisions and they belong behind a boundary.
No write actions. It never pages anyone, opens anything, or changes state. It answers questions and a human decides.
The shipped catalog is fictional. Every service, team, and handle in
catalog.tomlis invented. A test fails the build if anything employer-identifying appears in the repo.The timing model is a convention, not a standard. Cumulative minutes from impact start, carried forward when the chain climbs to another team. Reasonable, and not the only reasonable choice.
No cost or latency figures, because there are no model calls. The server is deterministic and local.
Gates
Built against a rubric frozen before the first line of code. The ones worth knowing:
Every tool answers through a real client speaking the wire protocol, not just as a function call in a test.
Every tool has a failure-path test proving it declines rather than guesses.
Tests were observed failing before each implementation existed.
Swapping the catalog changes every answer with no code edit, proven by a test.
The committed transcript regenerates, or the build fails.
No credentials, no network calls in the source, no employer content, no third-party imports. This gate blocks.
Maintenance
Resources
Unclaimed servers have limited discoverability.
Looking for Admin?
If you are the server author, to access and configure the admin panel.
Related MCP Servers
- FlicenseNot gradedqualityAmaintenanceMCP server for the Rootly incident management platform — alerts, incidents, on-call schedules

runframe-mcp-serverofficial
AlicenseNot gradedqualityCmaintenanceEnables managing incident response workflows including incidents, on-call, postmortems, and more through the Runframe platform using MCP tools.864MIT- AlicenseNot gradedqualityCmaintenanceEnables PagerDuty incident response operations including listing incidents, acknowledging and resolving incidents, looking up on-call schedules, and listing services.MIT
- AlicenseNot gradedqualityBmaintenanceSelf-hosted operational dashboard and MCP server that catalogs runnable services and their operational context, offering a read-only MCP endpoint to list projects, service status, runbooks, and reconciliation context.1Apache 2.0
Related MCP Connectors
Vendor status pages, TLS cert inspection, DNS propagation checks, and incident-response playbooks.
Software component catalog: search your org's services, docs, APIs, dependencies, and ownership.
Uptime, API and server monitoring with outages, reporting, on-call and status pages.
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
MCP directory API
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/LZBiala/oncall-router-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server