Keystone
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| KEYSTONE_TENANT | Yes | The tenant graph to use (e.g., 'falkordb') |
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 |
|---|---|
| overviewA | Size and freshness of the graph: people, active people, tracked modules, merged PRs, and the as-of date of the data. Call first when unsure what is in the graph. |
| find_modulesA | Turn a fuzzy phrase ('execution plan', 'browser api') into exact module ids. Use before any module-specific tool when the user did not give an exact id. |
| module_riskA | Bus factor and risk tier of ONE module: who holds its knowledge (authored vs reviewed share), whether they are still active, how load-bearing the module is (PageRank). Use for 'how risky is X', 'bus factor of X'. |
| risk_scanA | Rank every tracked module by succession risk (critical/high/medium/low) and count the tiers. Use for 'what is most at risk', 'where are we fragile', 'orphaned code'. |
| keystonesA | People ranked by what leaves with them: modules that would be orphaned and modules where they are the sole holder. Use for 'who can we not afford to lose', 'single points of failure'. |
| what_if_leavesA | Counterfactual: if this person left, which modules become orphaned or fragile? Runs on a GRAPH.COPY fork and diffs before/after; the live graph is untouched. Use for 'what if X leaves/quits/goes on leave'. |
| successorsB | Who could realistically take over a person's modules (or one module)? Multi-hop: who already reviewed their PRs, who knows adjacent modules that change together with the target. Use for 'who can step in for X', 'who should we pair with X'. |
| who_knowsA | Who holds the knowledge for a module or area, with authored/reviewed counts and recency. Use for 'who knows about X', 'who owns X'. Returns not_in_graph if nothing matches. |
| knowledge_mapB | Territories (module clusters that change together, found by label propagation), who holds each, and the brokers that connect people (betweenness). Use for 'how is knowledge organised', 'silos', 'who bridges teams'. |
| path_betweenC | Weighted shortest chain of shared knowledge between two people, or a person and a module (algo.SPpaths). Use for 'how is X connected to Y'. |
| recallB | What earlier sessions concluded or decided about a person or module (findings, decisions, open tasks), including notes about the people who hold a module. Call BEFORE planning so you do not repeat or contradict earlier work. |
| changes_sinceB | Compare the graph now with the last saved review: which modules got safer or riskier, who became top holder, and whether open pairing tasks actually progressed according to real PR activity. Use for 'what changed since last time', 'did the plan work'. |
| succession_reviewA | Full succession review for one person, run by three roles that coordinate only through graph state: Analyst (what-if + successors), Planner (simulates a pairing plan on a fork, writes a Decision and Tasks), Reviewer (re-verifies from the graph on a fresh fork). Writes memory. Use for 'make a plan for X', 'succession plan'. |
| draft_actionsA | Turn an approved succession Decision into concrete, reviewable artifacts: a CODEOWNERS patch per repo and an issue draft per pairing, each with the graph evidence. Dry-run: nothing is posted anywhere. Omit decision_id to use the latest approved one. |
| note_findingB | Save a short finding to memory, linked to the people/modules (exact ids) it is about. Only write what the graph showed. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
| succession_briefing | A ready-made briefing request for one person. |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
| tenants_resource | Graphs (organisations) available on this server. |
TDQS
Scored across 15 tools
Each tool targets a distinct resource or analysis angle: single-module risk vs portfolio risk, current knowledge holders vs multi-hop successors, keystone ranking vs per-person counterfactual. Descriptions explicitly state when to use which, so an agent can reliably select among closely related tools.
All names use lowercase snake_case with no camelCase mixing, and they are broadly descriptive. However, the set mixes verb-led commands (draft_actions, find_modules, note_finding) with noun-led queries (overview, keystones, knowledge_map, successors), so the pattern is not a uniform verb_noun convention.
15 tools fit a rich domain spanning graph overview, module discovery, risk analysis, person impact, counterfactuals, memory recall, review workflow, and artifact drafting. Each tool appears to serve a distinct part of the succession-planning workflow without obvious redundancy.
The surface covers discovery, analysis, planning, review, memory, and artifact generation, with no major dead ends. Minor gaps exist around explicit decision management (e.g., listing or approving decisions outside recall) and direct person/module listing, but core workflows are well covered.