Corey James- ~20,000lines of Rust behind one generic MCP server
- 35per-criterion check scripts with re-runnable transcripts
- B0–B9gated phases the build moved through
One generic core, one profile per API
The integration platform in FAFO Core and Function Forge puts an HTTP API behind a generic MCP (Model Context Protocol) server. The generic core is built once, and each API is a declarative connectivity profile, so a new integration is a matter of configuration and probes.
A field is real once a real call returns it
Integrating a third-party API usually starts from its documentation, and documentation describes fields an API does not always return. I decided the platform would treat a field as real only after a successful real call returned it.
A field in the documentation is a claim, and a field in a successful response is a fact.
Probing adds to the manifest only what successful calls returned, and the differences are kept.
A cheap gate before the expensive work
Validation is cheap, so it comes before any investment in tools. A validation harness with no server surface runs against the target before any tool is authored, and a gate that has never rejected anything is untested, so I gave it negative catalogs to reject.
See Closed by evidence.
Reads cached, writes checked against the source
Reads come from a cache. Writes go through a governed path that checks against current data before anything is sent to the third party.
The language-model help used to write profiles lives in a separate, short-lived developer server, never inside the server agents call.