grok-faf-mcp — FAST⚡️AF Edition

Home: faf.one/grok Live demo: grok.faf.one

FAF defines. MD instructs. AI codes.

First v0.2-conformant reader of the FAF Context Ingestion Contract — the open standard co-authored in public with @grok.

Install — one line

Add to ~/.grok/config.toml:

[mcp_servers.grok-faf-mcp]
url = "https://mcpaas.live/grok/mcp/v1"

Restart Grok TUI (or /mcps r) to refresh. Tools: faf_score, faf_validate, faf_get_tier, faf_estimate_tokens, faf_analyze (plus soul/memory ops).

Smithery: wolfe-jam/grok-faf-mcp — gateway at https://grok-faf-mcp--wolfe-jam.run.tools

Homebrew (local stdio):

brew install wolfe-jam/faf/grok-faf-mcp

Hosted on Cloudflare Workers — sub-ms cold start, no subprocess, edge-served. 4865-byte Zig WASM engine, parity-tested vs the Rust authority (xai-faf-rust). Externally validated by Grok S1 + S2 on 2026-05-27.

Verify the live contract:

curl https://mcpaas.live/grok/mcp/v1/info

Returns endpoint, protocol versions, engine details, tool list, and the architecture line: .faf=vROM | AI-in-session=RAM.

Sample corpus: xai-faf-proof/pilot — 10 records ready to score.

The 6 Ws - Quick Reference

Every README should answer these questions. Here's ours:

For AI: Read the detailed sections below for full context. For humans: Use this pattern in YOUR README. Answer these 6 questions clearly.

For the xAI / Grok Build team

Built for Grok and shaped by direct Grok feedback.
Open for native Grok Build integration, .fafm memory layer, refresh_faf primitives, or any other context features the team needs.
Live and dogfooded at https://grok.faf.one and https://mcpaas.live/grok/mcp/v1.

Context for Grok agents: faf-cli authors what Grok agents read from real project detection — bunx faf export --agents. The existing src/interop/grok.ts wires FAF MCP into .grok/config.toml. See FAF-CLI for Grok & xAI agents 👀.

The Problem

Every Grok session starts from zero. You re-explain your stack, your goals, your architecture. Every time.

.faf fixes that. One file, your project DNA, persistent across every session.

Without .faf  →  "I'm building a REST API in Rust with Axum and PostgreSQL..."
With .faf     →  Grok already knows. Every session. Forever.

One Command, Done Forever

faf_auto detects your project, creates a .faf, and scores it — in one shot:

faf_auto
━━━━━━━━━━━━━━━━━
Score: 0% → 85% (+85) ◇ BRONZE
Steps:
  1. Created project.faf
  2. Detected stack from package.json
  3. Synced CLAUDE.md

Path: /home/user/my-project

What it produces:

# project.faf — your project, machine-readable
faf_version: "3.3"
project:
  name: my-api
  goal: REST API for user management
  main_language: TypeScript
stack:
  backend: Express
  database: PostgreSQL
  testing: Jest
  runtime: Node.js
human_context:
  who: Backend developers
  what: User CRUD with auth
  why: Replace legacy PHP service

Every AI agent reads this once and knows exactly what you're building.

⚡ What You Get

URL:     https://mcpaas.live/grok/mcp/v1
Format:  IANA-registered .faf (application/vnd.faf+yaml)
Tools:   12 core by default (bunx) — re-grounding (refresh_faf/fafm/blend), LAZY-RAG, orchestration substrate, FAF essentials · extended utilities via FAF_TOOLS=all · 14 hosted (WASM-pure) on the URL
Engine:  Mk4 WASM scoring (faf-scoring-kernel)
Speed:   0.5ms average (was 19ms — 3,800% faster with Mk4)
Tests: 27 .ts files (~518 test declarations) — WJTTC parity (heavy local ↔ light hosted) + full suites. Runner: sh scripts/run-tests.sh (bun + flake retry)
Status:  FAST⚡️AF

MCP on a URL. Point your Grok integration at the URL. That's it.

Scoring: From Blind to Optimized

At 55%, Grok guesses half the time. At 100%, Grok knows your project.

Two Ways to Deploy

1. Hosted (zero install — recommended)

Point your MCP client at the production URL — edge-served on Cloudflare Workers, no subprocess, sub-ms cold start. WASM-pure tools only on this path (scoring, validation, refresh_faf).

{
  "mcpServers": {
    "grok-faf": {
      "url": "https://mcpaas.live/grok/mcp/v1"
    }
  }
}

2. Local (stdio — for FS-touching workflows)

Use the local stdio path when you need filesystem access (faf_init, faf_sync, file-mutating tools):

brew install wolfe-jam/faf/grok-faf-mcp   # macOS tap
# or
bunx grok-faf-mcp

Or via MCP config:

{
  "mcpServers": {
    "grok-faf": {
      "command": "bunx",
      "args": ["grok-faf-mcp"]
    }
  }
}

MCP Tools

Create & Detect

Drift & Orchestration (1.5 — the prestige release)

Sync & Persist

Read & Write

RAG & Grok-Exclusive

Plus 34 advanced tools available with FAF_SHOW_ADVANCED=true.

Performance

Execution:    0.5ms average (97% faster than v1.1)
Fastest:      3,360ns (version — nanosecond territory)
Slowest:      1.3ms (score — Mk4 WASM)
Improvement:  19ms → 0.5ms (3,800% faster)
Engine:       Mk4 WASM via faf-scoring-kernel
Memory:       Zero leaks
Transport:    stdio (local, bunx) · Streamable HTTP (hosted, Cloudflare Workers)

Benchmarked 10x per tool, warmed up, on local stdio execution. Hosted edge adds sub-ms cold start on top.

Orchestrator (faf_orchestrate_recommendation) characteristics: composition call — reads up to 6 files (.faf, .fafm, package.json, CHANGELOG.md, README.md, plus all 3 receipt logs), runs 2 analyzers (detectFafmDrift + checkId), evaluates the decision table, writes 1 receipt. Expected latency: tens of ms on warm cache; higher under cold-disk or very large .fafm corpora. Designed for occasional agent-initiated calls, not per-turn polling. detectFafmDrift is O(n²) in fact count (cross-fact n-gram recurrence) — comfortable up to ~hundreds of facts.

Architecture

grok-faf-mcp
├── src/
│   ├── server.ts             → MCP server (GrokFafMcpServer)
│   ├── handlers/
│   │   ├── championship-tools.ts  → 55+ tool definitions
│   │   ├── tool-registry.ts       → Visibility filtering (core/advanced)
│   │   └── engine-adapter.ts      → FAF engine bridge
│   ├── faf-core/compiler/faf-compiler.ts → Mk4 WASM scoring + Mk3.1 fallback
│   ├── types/                     → Canonical type substrate (1.5)
│   │   ├── drift-signals.ts       → DriftSignal · Contradiction · RepeatOffender
│   │   ├── refresh.ts             → RefreshMode
│   │   ├── escalation.ts          → EscalationLevel
│   │   ├── recommendation.ts      → RecommendationAction
│   │   └── receipts.ts            → ReceiptMetadata
│   ├── detection/fafm-drift.ts    → detectFafmDrift() — repetition-rate gauge
│   ├── integrity/check-id.ts      → checkId() — cross-stamp contradiction check
│   ├── orchestrator/
│   │   ├── repeat-offender.ts     → RepeatOffenderTracker
│   │   ├── take-a-hint.ts         → evaluateTakeAHint() — escalation ladder
│   │   ├── refresh-blend.ts       → runRefreshBlend()
│   │   └── recommendation.ts      → analyzeAndRecommend() + orchestrate()
│   └── telemetry/
│       ├── refresh-receipts.ts        → RefreshReceiptsLog
│       └── recommendation-receipts.ts → RecommendationReceiptsLog
├── smithery.yaml             → Smithery listing config
├── api/index.ts              → Vercel catch-site (legacy showcase surface; kept alive)
└── vercel.json               → Vercel routing for the catch-site

Production deployment: Cloudflare Workers via mcpaas-cf (serving mcpaas.live/grok/mcp/v1). The api/index.ts + vercel.json paths above stay alive as a catch-site for legacy/bookmarked links — they are no longer the production path.

Scoring pipeline: TypeScript compiler parses .faf → detects project type → The Bouncer injects slotignored for inapplicable slots → faf-scoring-kernel (WASM) scores → falls back to Mk3.1 if kernel unavailable.

Testing

27 test files (~518 test declarations) — WJTTC parity (heavy local ↔ light hosted) + full suites (recent runs green on CI):

sh scripts/run-tests.sh

Status & known limitations (v1.9)

v1.9.0 — The ZEPH Default Edition — the proven-fast Zig→WASM scoring path behind refresh_faf is now default-ON (same score, cheaper to compute; parity proven byte-identical — CI gate + 91/91 live). Kill switch USE_ZEPH=0 forces the canonical scorer. No tool-surface change; FRC tools stay opt-in behind USE_FRC. Everything below still applies; operating it honestly means surfacing what's NOT in here alongside what is.

Earlier: v1.8.0 — The Closed-Loop Edition — observability writes, token math is honest, FRC contract locked. The drift→refresh→re-ground loop can finally be measured. Earlier: v1.7.0 — The Grounded Memory Edition — ZEPH + the FRC layer over Grok Collections (faf_gate/faf_section/faf_memory), opt-in via USE_FRC/USE_ZEPH; 12-tool core unchanged. Earlier: v1.6.0 — The ZEPH Edition — the ZEPH fast path for re-grounding (refresh_faf/refresh_blend via Zig→WASM cascade.wasm, ~12µs, USE_ZEPH=1; faf-cli stays canonical, parity locked in CI).

What is fully supported:

• WASM-pure tools on the hosted endpoint (https://mcpaas.live/grok/mcp/v1 and client-specific routes) — scoring · validation · refresh_faf.
• refresh_faf and refresh_fafm as explicit, callable re-grounding primitives.
• refresh_blend as the baked-in two-intensity refresh (Cmd+R / Cmd+Shift+R analog).
• faf_orchestrate_recommendation — the heavy orchestrator that composes drift signals, recurrence, receipts, and take-a-hint into an advisory recommendation.
• faf_get_orchestration_policy — pure introspection of the effective policy without running the orchestrator (no drift detection, no receipt write — the quietest tool in the substrate).
• Full policy visibility (effective_policy) returned on every orchestration call AND surfaced standalone via faf_get_orchestration_policy.

Current limitations:

• faf_orchestrate_recommendation, faf_get_orchestration_policy, refresh_fafm, and refresh_blend require filesystem access and are only available via the local stdio path (bunx grok-faf-mcp / npx grok-faf-mcp). They are not exposed on the hosted WASM-pure endpoint. The hosted path serves the existing WASM-pure subset only (refresh_faf + scoring + validation).
• Receipt storage — cwd-relative JSON, pull-discoverable. Three append-only JSON files live at the repo root with stable schemas:
  code

  .faf-drift-index.json              ← RepeatOffenderTracker — per-slot recurrence counts
  .faf-refresh-receipts.json         ← RefreshReceiptsLog    — every refresh fire
  .faf-recommendation-receipts.json  ← RecommendationReceiptsLog — every orchestrator call
  

  Pull-discoverable by external tools (TAF, custom indexers, observability dashboards) — read on your own schedule, no callback/push API required. Promotion to a dedicated orphan branch (mirroring the TAF pattern) is documented but deferred per ship discipline; the cwd-relative JSON is the v1 bootstrap.
• No multi-process file lock on the receipt logs. Within a process, the JS event loop serializes writes. Multi-agent concurrent writes can race; future task.
• Aggressiveness tier hook — .faf:orchestration:tier reads 'conservative' (default — quietest, no noisy first-impression) · 'balanced' · 'aggressive'. active_tier always surfaced in hints.effective_policy for observability, and standalone via faf_get_orchestration_policy. The policy WRITER (faf_set_orchestration_policy) and scheduling (faf_schedule_heavy_re_ground) are not included in v1.5 — edit .faf:orchestration:tier: directly to override.
• No ack mechanism yet for recommendation receipts. acknowledged: false by default, never auto-flipped. Take-a-hint's ladder-reset semantics fire only on explicit ack — conservative by intent. Future task: explicit ack tool OR derived-from-subsequent-refresh-receipt timing.
• Outcome tracking ("did this recommendation actually help?") — needs a learning layer beyond 1.5 scope.

The honest split is intentional: hosted = fast, auditable, WASM-pure; local = full capability including filesystem. We will expand the hosted surface only where it can be done safely and without compromising the model.

Subordinate-not-daemon throughout. The orchestrator NEVER auto-fires the recommended tool. Agents surface the recommendation; the user (or higher agent) decides whether to act. Even severity: 'block' is advisory.

See the public verifier and curl https://mcpaas.live/grok/mcp/v1/info for the current contract.

Ecosystem

One format, every AI platform.

Same project.faf. Same scoring. Same result. Different execution layer.

Voice variant — grok-faf-voice (VML)

.fafm 🐘🎙️ — the voice variant of the .faf 🐘 family.

grok-faf-voice is the reference implementation of the Voice Memory Layer (VML) — what your voice agent remembers across sessions, devices, and model switches. Companion to grok-faf-mcp:

• grok-faf-mcp (this) — .faf Foundational Context Layer for Grok via MCP-on-a-URL.
• grok-faf-voice — .fafm Voice Memory Layer (VML) for Grok Voice via LiveKit + xAI realtime.

Same family. Different surface. Voice swappable; memory permanent.

PyPI · GitHub · Onboarding

For the xAI / Grok Build team

This MCP server was built for Grok and continues to be shaped by direct feedback from Grok itself.

Open for deeper collaboration on:

• Native Grok Build integration
• .fafm memory layer
• refresh_faf primitives inside the Grok TUI / CLI
• Any other context or orchestration features the team needs

I ship fast, test rigorously, and dogfood everything live on https://grok.faf.one and https://mcpaas.live/grok/mcp/v1.

Happy to:

• Open PRs
• Run private dogfood sessions
• Jump on a call
• Or just ship whatever moves the needle

Real software only. Just say the word.

Contributing

PR conventions, code style, CI doctrine, MCP-tool contribution path, npm publish discipline, architecture decisions: CONTRIBUTING.md.

xAI / Grok devs welcome — TL;DR setup at the top, F1-inspired tone throughout.

If grok-faf-mcp has been useful, consider starring the repo ⭐️ it helps others find it.

For xAI / Grok Build team

Open for deeper native integration, .fafm memory layer, or Grok Build CLI collaboration.
Happy to ship PRs, dogfood, or jump on a call. Just say the word.

License

MIT — Free and open source

Get the CLI

faf-cli — The original AI-Context CLI. A must-have for every builder.

npx faf-cli auto

Anthropic MCP #2759 · IANA Registered: application/vnd.faf+yaml · faf.one · npm · Talk to my Agent →