Get started

Architecture

acf-mcp is a local-first stdio server, deterministic, with no internal LLM call. Versioned and Ed25519-signed knowledge base. Three-module pipeline: input → rule engine → signed footer. Typical latency below 10 ms per call.

iNote

acf-mcp does not call any LLM internally. Every output is produced by a deterministic rule engine over a signed knowledge base. This is the auditability guarantee that makes the standard defensible to an auditor or a court.

Design principles

Local-first — stdio transport by default, launched by the client on demand, no outbound network call in nominal operation.
Deterministic — same input + same doctrine version ⇒ same output, byte-for-byte. No temperature, no random seed, no LLM.
End-to-end signed — every output embeds doctrine_hash, doctrine_signature (Ed25519) and doctrine_public_key. Verifiable offline.
Versioned — the knowledge base is frozen per release (doctrine_version + doctrine_hash). No silent drift possible.

Processing pipeline

Every tool call passes through three modules in this strict order. Typical end-to-end latency is below 10 ms (cached disk reads, in-memory lunr index, constant-time Ed25519 signing).

text

client (Claude Desktop, Cursor, ...)
   |
   |  stdio JSON-RPC (MCP)
   v
+-------------------------------------------+
|  acf-mcp server (Node.js >= 18)           |
|                                           |
|  1. input validation (zod schemas)        |
|     |                                     |
|     v                                     |
|  2. rule engine (deterministic matcher)   |
|     - loads rules/*.json at startup       |
|     - lunr index for READ tools           |
|     |                                     |
|     v                                     |
|  3. signed footer (Ed25519)               |
|     - doctrine_hash + doctrine_signature  |
|     - generated_at + regulatory_snapshot  |
+-------------------------------------------+
   |
   v
deterministic, signed JSON output

1. Input validation

Every tool declares a zod schema. Enum fields (e.g. autonomy_level ∈ {N0,N1,N2,N3}) are validated against the doctrine’s canonical list. A description or use-case domain shorter than 20 characters is rejected immediately, with no engine call.

2. Rule engine

The engine loads its JSON rule files from disk at startup. For REASON tools, it is a deterministic pattern matcher (canonical-input → doctrine-fragment lookup table). For READ tools, it is an in-memory lunr index (full-text search over the signed corpus).

3. Signed footer

The engine result is serialised canonically (JCS — RFC 8785), SHA-256 hashed, Ed25519-signed with the doctrine key, then wrapped in an object embedding doctrine_version, doctrine_hash, doctrine_signature, doctrine_public_key, regulatory_snapshot and generated_at.

See the doctrine signatures page for the cryptographic detail and three reference verifier implementations.

MCP resources

Resources are markdown files with YAML frontmatter, served under canonical acf://… URIs. The frontmatter carries version, hash and signature; the body carries the pedagogical content. The server simply streams these files.

text

acf://principles/p1-traceability
acf://fiches/acf-08-decision-register
acf://glossary/ddao
acf://regulator/eu-ai-act/article-26

Performance

Typical REASON tool latency: 2–6 ms (validation + lookup + signing).
Typical READ tool latency: 4–9 ms (lunr query + serialisation).
Server memory footprint: ~80 MB at startup (corpus + index).
No network call in nominal stdio mode. No LLM call, ever.

Stated boundaries

acf-mcp produces a defensible preliminary qualification, not legal advice. The server does not certify an agent’s compliance — it provides the signed knowledge base, the reasoning tools and the cryptographic trace. The final decision belongs to the DDAO (Designated Deployer of Autonomous Operations) or the competent counsel.