READ-ONLY MCP · EVIDENCE VALIDATION

Enterprise Knowledge Validation MCP

Is the knowledge current? Is the evidence enough?

Repository artwork, adapted to the portfolio palette: two read-only MCP tools validate synthetic evidence for human review.

Problem

Finding a document does not establish that it is the effective version, that an approval covers the exact action, or that supporting evidence is complete.

What I built

An independent Python Model Context Protocol server with two read-only tools: check_procedure_status and assess_action_readiness. They return typed assessments, cited records and explicit blockers from a validated synthetic knowledge snapshot.

Architecture

FastMCP handles discovery and calls over stdio or loopback Streamable HTTP. Pydantic defines strict contracts. Deterministic logic loads one validated snapshot per assessment. The packaged JSON is the local trust root; synthetic citations identify records in that snapshot rather than external URLs.

Validation decisions

Approval evidence must match the action, exact procedure version, scope, required role and time window. Caller-supplied approval claims cannot substitute for stored evidence. Duplicate fields, ambiguous records or contradictory current versions invalidate the store. Failures accumulate explicit blockers.

Real demonstrations

In an official-SDK session, SOP-104@1.0 is reported as superseded, cites its approved replacement and remains held for review. ACT-001 is blocked because stored approval evidence is missing. ACT-002 is a positive control eligible for human review, but it still returns human_review_required=true and execution_authorized=false.

Verification

The preserved suite contains 106 tests, including 36 real MCP protocol cases. Official clients exercise both transports, discovery, typed responses, invalid inputs, spoofed approvals, corrupted evidence and recovery. GitHub Actions for commit 494e081 passed the suite, demonstration, package build and installed-wheel demonstration outside the checkout. These are recorded checks, not a production-readiness claim.

Trust and limitations

All 23 records are fictional. Evaluation is frozen at October 16, 2026, 12:00 UTC, so results do not establish readiness today. No live Glean or Stellix connection, enterprise authentication, source ACL enforcement, operational deployment, employee adoption study or organizational ROI is established. The loopback server is a local demonstration; the website presents its evidence, not a public MCP endpoint.

Tradeoff

A small deterministic snapshot makes the rules inspectable and repeatable. It does not authenticate the fixture's stored names or roles: a local editor can forge consistent evidence. A real pilot would need trusted sources, identity, authorization and workflow validation before integration.

Contribution and provenance

I prepared this independent portfolio project with ChatGPT/Codex-assisted code, testing, documentation and visual design. The public repository is available for inspection under an All Rights Reserved notice. Its original diagrams and response captures retain their repository provenance.

Inspectable tool responses

Selected JSON fields rendered from an actual official-SDK stdio session using fictional records. This is a response transcript, not a separate application interface.

Recorded MCP responses: a superseded procedure is held for review; an action is blocked for missing approval evidence.

View repository

Verification record · Verified GitHub Actions run · Full stdio transcript