knowledge-mcp
A shared-memory server for AI agents that screens every write and blocks saving if the check fails.
decision
A developer connecting AI agents to persistent memory decides which store methods can read or write. The server rejects a planted deny-list match instead of letting a tool save it for later sessions.
baseline
The original per-tool checks are the comparison: the same planted value produced inconsistent outcomes. One store boundary replaces those repeated checks. A regular-expression deny-list remains a limited detector.
review
On rejection, the agent receives the field and pattern type without the matched text. Its operator must remove the sensitive content before retrying. An unclassified store method prevents startup and requires the developer to classify it.
data
The test plants synthetic strings and checks persisted state, including the audit log. Reads are not screened. The stdio server trusts its host and has no authentication. Browser database access and row isolation were not tested against a live service. Retention and deletion policies are outside the demonstrated boundary.
platform
Model Context Protocol (MCP) exposes seven read tools and ten write tools to agent clients. The reusable store gate screens each write argument. The 324-case client/server harness and raw-store canary test wiring as well as matching. It does not supply database authorization for browser consumers.
limits
The deny-list covers six pattern types, not arbitrary sensitive information. No live database authorization or multi-user isolation result is claimed.
Evaluation
Original baseline. All runs on 2026-10-30, Node 24.14.1. The server exposes 7 read and 10 write tools over JSON-RPC on stdio, and each tool declares its access so the server can publish the MCP readOnlyHint. The gate walks every string, object key and number, checks each against the deny-list raw and after Unicode NFKC normalization with invisible characters removed, and returns ok only if nothing matched and nothing went wrong.
Evidence: npm test | 91 tests, 91 pass, 0 fail (node:test, about 1.3 s)
Evidence: Registry write-path test | 324 cases across the 10 write tools, each through a real MCP client and server
Evidence: Canary: tools wired to the raw store | The harness flags all 8 write tools that take new content
Evidence: Manual: screening disabled for putFile | 3 memory tests failed
Evidence: Manual: unclassified store method added | Every runtime build throws, so the server cannot start
Evidence: npm run demo | 7 write tools, one benign and one planted write each: 7 written, 7 rejected, 0 planted values left
Original version, 11 probes: Wrote the planted value unchanged | 7
Original version, 11 probes: Masked it and wrote anyway (record, decision and capture body text) | 3
Original version, 11 probes: Blocked the write, but saved the text around the match to the audit log (a memory write) | 1
- The deny-list is a set of regular expressions. It catches only what its patterns describe and is not a general PII detector. The example list is US-formatted and has false positives and false negatives.
- Reads are not screened. Everything the store holds passed the gate when it was written or loaded.
- The stdio server trusts its MCP host. There is no authentication.
- The browser client has only been tested against a fake client, with no live database or row-level security policy.