MCP server for Standfast, a shared knowledge layer for coding agents. Provides tools for reading, proposing, and reconciling knowledge atoms (decisions, conventions, constraints) with code.
Standfast MCP exhibits strong schema discipline and domain-specific naming. All 6 tools have complete input schemas with proper types, enums, and descriptions. Tool names are action-oriented (read, propose, status, context, search, reconcile) and domain-appropriate. Descriptions are substantive (100-250 chars), explaining WHAT and WHEN. However, output schemas are not documented in the visible code, and error handling guidance is absent. The propose and reconcile tools correctly enforce write semantics via Risk annotations. Parameter descriptions are detailed (e.g., sourceSpan with nested properties, budgetTokens with min/max). No security issues detected, no credentials in params. Composition is clean: each tool has one responsibility, and tool outputs should chain (e.g., read returns IDs that propose accepts). Baseline: 549 production tools average 18-char names and 194-char descriptions; Standfast aligns well (names 4-9 chars, descriptions 100-250 chars).
Get the ratified decisions, conventions and constraints that govern the work you are about to do. Returns a set assembled under your token budget, ordered constraints first; `truncated` says whether anything was left out.
Propose a decision, convention or constraint. It is stored as provisional and must quote the text it came from. Only a human can ratify it; you cannot.
Read one atom, document or section from Standfast, with the source quote it was drawn from.
Submit verdicts on whether code you have just read still honors the atoms that govern it. No field accepts code — a verdict, a path and line numbers only, and a violation must cite the lines that disprove the atom.
Search a project's ratified knowledge by wording, by meaning, or both, and get back the documents it projects from.
Output schemas not documented. LLMs cannot plan downstream calls or extract fields without knowing what read(), context(), search(), and reconcile() return. Baseline: 100% of A+ tools document return types.
No error recovery guidance. Tools lack descriptions of failure modes and recovery steps. E.g., propose() could fail if sourceQuote is not found in section, LLM needs guidance to retry with adjusted quote or call search() first.
reconcile() parameter 'items' is complex (array of objects with conditional required fields). lineStart/lineEnd are required only for verdict='violated', but schema does not enforce this. LLM may omit them for violated verdicts, causing silent failures.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 64 | 2026-07-28+ | v2 |
Summarise a project's knowledge: how many atoms are provisional, canonical or rejected, and how many are waiting on a human to ratify.
context() budgetTokens parameter defaults to 2000 but accepts up to 200000. No guidance on how to choose. LLM may pick extreme values, wasting tokens or truncating results unexpectedly.
search() mode parameter defaults to 'hybrid' but lacks explanation of when to use 'lexical' vs 'semantic'. LLM cannot reason about which mode fits the query intent.