grok-faf-mcp v2.1 — The New Era Edition

Grok asked for MCP on a URL. This is it.

Persistent Project Context for xAI Grok.

URL-based • Zero config • Just works

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

FAF defines. AGENTS.md instructs. AI codes.

v2.1.0 — The New Era Edition

Glass-box tools: every Grok tool now says what it does — reads, writes or rewrites — so your client knows when to ask first. New card, new look at grok.faf.one.

• Every tool is labelled. All 20 tools carry MCP tool annotations, checked against what each handler really does: 7 read only, 3 can delete or overwrite (faf_init with force, faf_clear, faf_write), the rest write without losing anything. Only rag_query reaches the network (xAI Collections).
• Honest about receipts. refresh_faf, refresh_fafm, refresh_blend, faf_orchestrate_recommendation and the FRC tools (faf_gate, faf_section, faf_memory) append small receipt files to your project folder, so they are labelled as writers. refresh_fafm no longer says "Read-only".
• Its own card. Grok FAF now has a FAF passport (agent.fafa) at grok.faf.one/.well-known/fafa, with AI Catalog and ARD entries that point to it. The MCP Server Card is the hosted one, also at grok.faf.one/.well-known/mcp/server-card.json.
• A new look. grok.faf.one is redesigned, with the current facts: 19 tools hosted, 12 by default locally.
• Node 22 or later, like faf-cli 8 and the rest of the FAF family.

Earlier: v2.0.0 — The Always33 Edition — one engine, one number: every score is faf-cli 8's always-33 kernel, on npm and on mcpaas.live. ZEPH is opt-in until the Zig engine is always-33.

☆ Bookmark grok.faf.one for later.

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. The hosted endpoint scores always-33 — the same number as the npm package. 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. Scores and validates with the faf-kernel WASM (always-33, the same engine as the npm package) since mcpaas-cf 1.8.1; a Zig WASM engine handles token estimates and tier. 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. faf-cli's src/interop/grok.ts wires this MCP into .grok/config.toml (that file lives in the faf-cli repo, not here). 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 · 19 hosted (WASM-pure, served by mcpaas-cf) on the URL
Engine:  faf-cli 8 — faf-scoring-kernel 3.0.0 (Rust → WASM, always-33)
Speed:   0.5ms average (was 19ms — 3,800% faster with Mk4)
Tests: 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:       faf-cli 8 (faf-scoring-kernel 3.0.0, always-33)
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/commands/score.ts → faf-cli scoreFafYaml (always-33)
│   ├── 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: faf-cli's scoreFafYaml → the always-33 kernel (faf-scoring-kernel, Rust → WASM) scores the file as written: 33 slots, slotignored slots drop out of the denominator. No per-type rewriting, no fallback scorer — the same number faf-cli, claude-faf-mcp and faf-mcp give.

Testing

WJTTC parity (heavy local ↔ light hosted) + full suites (green on CI):

sh scripts/run-tests.sh

Status & known limitations (v2.1)

v2.1.0 — The New Era Edition — glass-box tools (every tool labelled read, write or rewrite), its own FAF passport at grok.faf.one, a new look. Scoring is unchanged from v2.0.0.

v2.0.0 — The Always33 Edition — one engine, one number: faf-cli 8's always-33 kernel on npm and on mcpaas.live. ZEPH is opt-in until the Zig engine is always-33. FafCompiler upgraded to the Always33 fafb model — parity across frontier models, Enterprise/Teams ready.

Everything below still applies; operating it honestly means surfacing what's NOT in here alongside what is.

Earlier: v1.10.0 — The No-Fluff Edition — no fluff in a project.faf. faf_enhance is gone. RAG default is grok-4.6. Fill stays on faf_auto / faf_go.

Earlier: 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. FRC tools stay opt-in behind USE_FRC.

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:

• 19 tools on the hosted endpoint (https://mcpaas.live/grok/mcp/v1 and client-specific routes) — scoring · validation · refresh_faf · a content-in faf_orchestrate_recommendation · the FRC trio · souls and search. The live list is at …/grok/mcp/v1/info.
• 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_get_orchestration_policy, refresh_fafm, refresh_blend, faf_init and faf_sync need filesystem access and run only on the local stdio path (bunx grok-faf-mcp / npx grok-faf-mcp). The hosted faf_orchestrate_recommendation takes file contents instead of reading your repo, and has no receipts or recurrence history (it reports those under partial[]).
• Receipt storage — cwd-relative JSON, pull-discoverable. Three append-only JSON files live at the repo root with stable schemas:
  Copy

  .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.

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.

Citation

If you use grok-faf-mcp or the .faf / .fafa formats in research or production, please cite the format papers:

Wolfe, J. (2025). Format-Driven AI Context Architecture: The .faf Standard for Persistent Project Understanding. Zenodo. https://doi.org/10.5281/zenodo.18251362

Wolfe, J. (2026). Why Agents Need a Passport: .fafa — Portable Identity for the Agentic Era. Zenodo. https://doi.org/10.5281/zenodo.21951641

BibTeX

@article{wolfe2025faf,
  title     = {Format-Driven AI Context Architecture: The .faf Standard for Persistent Project Understanding},
  author    = {Wolfe, James},
  year      = {2025},
  month     = {nov},
  publisher = {Zenodo},
  doi       = {10.5281/zenodo.18251362},
  url       = {https://doi.org/10.5281/zenodo.18251362}
}

@article{wolfe2026fafa,
  title     = {Why Agents Need a Passport: .fafa — Portable Identity for the Agentic Era},
  author    = {Wolfe, James},
  year      = {2026},
  month     = {aug},
  publisher = {Zenodo},
  doi       = {10.5281/zenodo.21951641},
  url       = {https://doi.org/10.5281/zenodo.21951641}
}

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 →