precedent
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.
Precedent tells you which architecture decisions (ADRs/RFCs) are still good law. Decision records are immutable, so later decisions quietly supersede, reverse or withdraw parts of earlier ones; the old text still says "Accepted". Never act on a decision's text alone.
Workflow:
Before changing code or designing something, call
preflightwith the task and/or the file paths. Treatlive_clausesas binding, and follow the decision named instale_clauses[].byinstead of the stale text.Use
decision_statusto inspect one decision (clause-level standing + the quoted evidence).Writing a new decision? First call
find_overlapswith your draft text: it points at the clauses you would overrule (declare them intreats) and at ground that is already out of force (cite the replacement instead). It ranks; you decide.If your change should overrule an earlier decision, do NOT edit it: call
propose_decision(dry run by default). It reports which decisions change standing and who relies on what you are overruling. Fix every error (each has afix) before resubmitting; commit only when asked.query_graphruns read-only Cypher for anything else (seegraph_schema).
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
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| preflightB | Which decisions must you respect before doing |
| decision_statusB | Is this decision still good law? Clause-level standing, who treated it and the quoted evidence, who relies on it. |
| search_decisionsB | Hybrid search (BM25 + clause BM25 + vector) over decisions; each hit carries its standing. |
| explain_linkB | Shortest path of citations/treatments between two decisions - why are they related? |
| cite_checkC | Structural findings: stale statuses, reliance on superseded clauses, ghost paths, near-duplicates... |
| graph_schemaA | The graph model and example Cypher for |
| query_graphB | Run a READ-ONLY Cypher query. Rows are capped; a capped result says so in |
| find_overlapsA | Before you write a decision: which existing clauses does your draft overlap? Paste the draft text (and/or the files it
touches). Flags clauses that still bind (declare them in |
| propose_decisionA | Review a draft decision against the graph before it lands (dry run unless commit=true).
|
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 9 tools
Each tool has a distinct role: preflight (pre-work obligations), find_overlaps (pre-authoring overlap check), decision_status (single-decision standing), cite_check (corpus-wide structural audit), search/explain/query for retrieval, and propose_decision for writes. The closest pair is preflight vs. find_overlaps, which both surface binding clauses, but their descriptions clearly separate 'before doing a task' from 'before writing a decision'. decision_status and cite_check also overlap mildly on staleness reporting, though at different granularities.
All names are lower snake_case, which is consistent. Most are verb_noun (search_decisions, explain_link, cite_check, find_overlaps, propose_decision, query_graph), but decision_status and graph_schema are noun_noun and 'preflight' is a bare noun with no verb, so the pattern is not fully uniform. Still readable and predictable enough.
Nine tools is well within the ideal range for a decision-graph server. Each tool maps to a recognizable workflow step (orient, search, inspect status, audit, draft, propose), and graph_schema is a small but justified companion to query_graph. No obvious redundancy or padding.
The surface covers the full decision lifecycle: search, standing checks, citation tracing, structural auditing, drafting, and committing via propose_decision. Minor gaps remain, such as no explicit get_decision for fetching a full decision body by ID (workable via search or query_graph) and no listing/timeline operation. Agents can work around these through the Cypher escape hatch, so no dead ends.