Works with any system that exposes a GET endpoint for the written record.
Fourgate does not need a vendor-specific connector to check an outcome. If your system of record can return the record your agent just wrote, over HTTPS, Fourgate can read it back and compare the contracted fields.
Your agent
MCP client
fourgate guard
local process
Your MCP server
no code changes
System of record
the API you write to
Local stdio MCP servers
RuntimeAny MCP server launched as a local stdio process with a command. fourgate guard wraps that command at runtime; fourgate scan exercises contracted writes against a disposable test account.
HTTP GET read-back
Read-backA bounded GET to an API that can return the written record. The read credential is sent as a Bearer token by default, or as a custom header (for example X-Api-Key) or Basic auth, or with no auth. Fixed, non-secret headers such as an API version can be added; credential-looking header names are rejected there, so a token can only come from an environment variable.
GitHub Issues read-back
Read-backTemplateA built-in read-back type for GitHub Issues. The bundled GitHub contract is a template: it still needs a disposable repository, tokens and real end-to-end acceptance.
Local command verifier
VerifierA trusted local command that receives only the contract-selected fields. The bundled one, fourgate.verify_http, is the generic HTTP read-back above.
CI template
CITemplateA copy-paste GitHub Actions workflow that runs fourgate scan on manual dispatch and fails the job on any FAIL or UNKNOWN. Fourgate's own CI runs its steps against the bundled demo fixture. Customer CI is unvalidated.
Wrap your server.
Your MCP client keeps its entry for the server. Only the command changes: fourgate guard runs your server behind it.
{ "mcpServers": { "my-server": { "command": "python", "args": ["your_server.py"] } }}Same thing as a shell command
python your_server.py
The file name and shape depend on your MCP client; only the command changes. runtime.json is the contract file fourgate init writes.
One write tool, one read-back, two small files.
fourgate init writes these from flags, validates them with the same loaders scan, guard and doctor use, and never reads secret values, starts the server or contacts an endpoint. The files contain only the name of the credential's environment variable.
fourgate init \
{ "type": "http", "url_template": "https://api.example.com/issues/{record_id}", "expected_fields": { "title": "title" }, "token_env": "READBACK_TOKEN", "missing_statuses": [ 404 ], "attempts": 3, "interval_ms": 250, "timeout_ms": 1500}secret_env- Lists the read credential's variable. fourgate guard removes it from the MCP server's environment; the verifier still receives it.
missing_statuses: [404]- Opts a 404 into FAIL. Only do this after confirming the read-only identity can see the relevant records; otherwise a missing record and missing access look alike.
timeout_ms- At most 1500 for the read-back; the runtime caps each verifier at 2000 ms. Anything slower is UNKNOWN.
Not supported yet
- Remote MCP transport (HTTP-based MCP servers). Only command-configured local stdio servers are covered.
- A hosted control plane. There is no Fourgate hosted endpoint and no telemetry.
- Customer CI, Desktop UI, and production reliability. Those paths are unvalidated in limited beta 0.4.0b1.
- Non-HTTP databases. There are no database adapters; read-back is an HTTP GET.
- Generated contracts. Outcome contracts are written by hand and approved by a human.
- Dashboards, alerting, a gateway, a retry engine or automatic compensation.
Not sure your API has the right GET endpoint?
Finding the read-back endpoint for each write is part of the scope call.