Rootpath MCP Server
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| FALKORDB_URL | No | URL of the FalkorDB instance holding the service graph, e.g. redis://localhost:6380 | |
| ONCALL_ALLOW_ACTIONS | No | Set to 0 to force every action to be a dry run, for read-only deployments. | 1 |
| ONCALL_CHANGE_FREEZE | No | Set to 1 to activate a change freeze that blocks all real actions. | 0 |
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": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| get_service_healthC | Live health from the services' stats endpoints (last 20s). |
| get_logsC | Recent log entries, de-duplicated: distinct messages with counts, plus the latest entries. |
| rank_suspectsA | Rank root-cause suspects for a symptom by walking the dependency graph downstream from it, combining live health, recent changes (deploys + flag flips), and betweenness centrality. Also returns the top suspect's runbooks and the past incidents caused there, with their fixes. |
| get_blast_radiusB | Who is affected if |
| recent_changesB | Deploys and feature-flag flips in the time window, scoped through the graph to |
| trace_dependency_pathB | Shortest call path between two services (algo.SPpaths), with live health per hop. |
| get_ownerC | Owning team, who is on call, escalation path and runbooks for a service. |
| find_similar_incidentsA | Search incident memory: full-text match on past symptoms, boosted when the past incident involved the same service. Returns root causes and what fixed them. |
| explain_incidentB | The full evidence chain for an incident: impacted services, root cause, actions and why. |
| query_graphA | Escape hatch: run your own read-only Cypher (RO_QUERY, 2s timeout, max 100 rows). |
| open_incidentB | Open an incident in the graph (or return the one already open for these services). |
| notify_ownerC | Page the on-call person of the owning team (Slack/Discord webhook if configured). |
| resolve_incidentB | Close the incident and write what was learned into incident memory. |
| rollback_serviceC | Redeploy the version that ran before the latest deploy of |
| restart_serviceC | Restart a service's container (clears in-memory state such as stuck connection pools). |
| set_feature_flagC | Turn a feature flag on or off (takes effect within a second, no deploy). |
| verify_recoveryA | Poll live health until |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 17 tools
Most tools have clearly distinct purposes organized around a diagnosis→remediate→verify workflow (rank_suspects, get_blast_radius, recent_changes, trace_dependency_path), so misselection is unlikely. Minor overlap exists between verify_recovery and get_service_health (both report health) and between rank_suspects and explain_incident/find_similar_incidents (all surface past-incident context), but descriptions disambiguate well enough.
Nearly all names follow a predictable snake_case verb_noun pattern (get_owner, open_incident, resolve_incident, restart_service, verify_recovery). A couple of noun-only names (recent_changes) break the pattern slightly, but the convention is clear and readable throughout.
17 tools is slightly above the ideal band, but each covers a genuinely distinct operation across a broad incident-response domain (detection, diagnosis, remediation, communication, verification) and none feels redundant. The surface is well-scoped for the complexity of the purpose.
The set covers the full incident lifecycle: diagnosis (rank_suspects, blast radius, changes, paths, ownership), memory search (find_similar_incidents, explain_incident), incident management (open/notify/resolve), remediation (rollback, restart, feature flag), verification (verify_recovery, health, logs), plus a query_graph escape hatch. No obvious dead ends for the stated purpose.