Fourgate documentation

Fourgate catches MCP tools that say "success" when nothing actually happened. 0.4.0b1 is a limited beta. Supported paths are local command-configured stdio. Customer CI, the Desktop UI, and production reliability are unvalidated. There is no remote MCP transport, no hosted endpoint, and no telemetry. Shadow is the default; enforce acts only on a confirmed FAIL.

After a connector reports success, Fourgate extracts only the fields a contract approves, runs a deterministic verifier against the system of record, and records one of three outcomes: ✓PASS, ✕FAIL or ?UNKNOWN. No LLM makes that decision.

Where to start#

• Quickstart: install, run fourgate demo, and read the three verdicts.
• Concepts: outcome contracts, read-back verification, shadow and enforce mode, failure behavior, and why UNKNOWN is never PASS.
• Protect your first tool: init, doctor, scan, guard, summary, in that order.
• Reference: commands and flags, contract JSON, the outcome log, and exit codes.
• Security summary: what runs where, what is stored, and what leaves your machine.

What 0.4.0b1 covers#

• Command-configured local stdio MCP servers only. Remote MCP transport is not supported.
• Independent read-back returns PASS, FAIL, or UNKNOWN. No LLM decides the verdict.
• Contracts are written by hand and approved by a person. Generating them is not implemented.
• The bundled verifier, fourgate.verify_http, is a generic HTTP GET read-back. There are no database adapters.
• There is no hosted control plane, dashboard, alerting product, gateway, retry engine, or automatic compensation.
• Customer CI, Desktop UI execution, and production reliability are unvalidated.