A read-only MCP server for inspecting, searching, and validating governed context records with freshness-aware reconciliation.
search_context — run a bounded, ranked search over synthetic organizational context; current records rank first, then stale, then invalid, with source IDs and visible freshness or evidence issues on every match. Accepts query plus optional asOf and limit.
validate_record — validate a context record's schema, provenance coverage, claim support, and freshness boundary. Accepts record plus optional asOf.
explain_source — show a declared source and the exact claims it supports on one context record. Requires recordId and sourceId.
inspect_ingestion — show the deterministic receipt linking one context record to its synthetic Markdown source. Requires recordId.
Safety posture — all four tools are read-only, idempotent, and non-destructive; no writes, no task execution (taskSupport: forbidden), and no authorization or record-level access control.
Click on "Deploy 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., "@Context Layer Lab are all scheduled automations actually healthy right now?"
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.
A small, inspectable reference implementation for stopping AI agents from acting on stale operational context.
Open the local-first diagnostic: no install, loads a synthetic snapshot, fully interactive.
07:30 status dashboard: GREEN (valid until 07:55)
08:02 nightly export: SUCCESS
08:40 docs build: FAILED
09:05 weekly report: finished, output not published
17:30 data sync: due later today, not counted as failed
Naive answer: Yes, the dashboard is green.
Governed answer: No, two lanes need attention.The scenario is synthetic and public-safe, but the failure class is real: aggregate status commonly outlives the evidence it summarizes. This lab reconciles freshness, schedule state, and evidence specificity before it will answer "are all scheduled automations healthy?" It does not simply repeat whatever the last dashboard said.
Related MCP server: artagon-vault-mcp
BM25F freshness-aware retrieval: 10/10 cases correct. Current records
rank above stale and invalid ones; BM25F score orders records within each
state. Whole-token, quality-flagged, bounded search, no embeddings. Full
numbers, including a three-way naive vs. recency-only vs. governed
contrast, in docs/eval-report.md.
Newer terminal receipts override an expired aggregate, and a not-yet-due
lane is never mislabeled as failed (see the operational invariant matrix in
docs/architecture.md).
Every decision-bearing summary, receipt, and lane schedule is bound to a source-linked typed assertion. A scenario outcome that contradicts its own evidence is rejected, not silently trusted.
17 deterministic cases pass against the real reconciliation and retrieval
code, no model call: npm run eval (7 record and operational, 10
retrieval).
This is not a RAG benchmark, vector database, or production authorization layer, and it does not claim schema validation makes information true. It is the smaller evidence-reconciliation layer that should exist before an agent is trusted to summarize operational state.
Requires Node.js 22+.
npm install
npm run check
npm run demonpm run demo prints the scenario above from the real reconciliation code:
Question: Are all scheduled automations healthy?
As of: 2026-07-28T09:10:00Z
Naive answer: healthy. It repeats the dashboard observed at 2026-07-28T07:30:00Z.
Governed answer: attention. 2 of 3 due lanes need attention.
Why:
- The dashboard record is stale. The record expired at 2026-07-28T07:55:00Z.
- 3 newer run receipts supersede it.
- Docs Build: failed (docs-build-receipt).
- Weekly Report: preserved_local (weekly-report-receipt).
- Data Sync: not due yet, so it is not counted as failed.npm start starts the read-only MCP server on stdio. It prints nothing and
waits for a client; see MCP tools for the
client config.
To apply the pattern to a company knowledge base, see
docs/how-to-adopt.md.
Generate a portable diagnostic snapshot the console can open directly. Parsing and rendering happen in the browser; nothing is uploaded:
npm run diagnose -- --output snapshot.jsonContext Layer Lab -> diagnose what current evidence supports
Governed Action Lab -> prepare/approve what may execute, under whose authority
-> execute/verify with what receiptThis lab establishes what current evidence supports. Its companion,
Governed Action Lab
(live console), starts at
that boundary and decides what may execute, under whose authority,
and with what receipt. They are one system in two repos, not two unrelated
projects. The real command sequence between them, with real output, is in
governed-action-lab's docs/pair-walkthrough.md.
Status: reference implementation, not a production system. This
repository demonstrates governed context records, provenance, validity
windows, freshness-aware retrieval, and a naive-versus-governed failure
contrast. It does not compete with production context or memory platforms on
retrieval scale, storage architecture, access control, or poisoning defense.
Authorization and record-level access control are out of scope; recency comes
from an explicit validUntil, not inferred content. See
docs/architecture.md for the
full list.
docs/architecture.md: MCP tools, retrieval, data
contract, evaluations, adapters, and full development checks.
docs/eval-report.md: auto-generated numbers and the
naive/recency-only/governed contrast.
docs/adr/: six architecture decision records.
docs/how-to-adopt.md: how to put this pattern in
front of a real agent, and what production still needs.
CONTRIBUTING.md: development checks and how to add an
eval case.
Built with Claude Code and Codex under my direction. I set the design and approve every release; the two agents wrote and cross-reviewed much of the code. Every change passes CI and review before release.
MIT
Show a declared source and the exact claims it supports on one context record.
Inputs: recordId (required), sourceId (required).
Show the deterministic receipt linking one context record to its synthetic Markdown source.
Inputs: recordId (required).
Search synthetic organizational context. Returns a bounded, ranked set: current records first, then stale, then invalid, with source IDs and visible freshness or evidence issues on every match.
Inputs: query (required), asOf, limit.
Validate a context record's schema, provenance coverage, claim support, and freshness boundary.
Inputs: record (required), asOf.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
Loading tool schema changelog…
Scored across 4 tools
The four tools target distinct actions: search, validate, explain source claims, and inspect ingestion receipts. explain_source and inspect_ingestion both touch provenance, so minor overlap exists, but their descriptions make the different focuses clear enough.
All tool names follow a consistent snake_case verb_noun pattern: explain_source, inspect_ingestion, search_context, validate_record. There are no deviations or mixed conventions.
Four tools is well-scoped for a focused context-inspection and validation layer, and each tool has a clear role with no obvious redundancy. The count sits comfortably in the typical 3-15 range.
The surface covers search, validation, source-claim explanation, and ingestion receipt inspection, but lacks mutating lifecycle operations such as create, update, delete, or a direct get-by-ID. For a context layer, these are notable gaps unless the intended scope is strictly read-only inspection.
Guarded MCP server for agent-readable business truth, provenance, readiness, and discovery.
Read-only Remote MCP for externally grounded AI agent trust receipts.
Read-only MCP server for The Quiet Protocol's engines, benchmarks, proof, and business data.
Read-only MCP server for AIStatusDashboard status, incidents, metrics, and fallback recommendations.
