Corey James- 18tool surfaces declared in YAML
- ~180actions across those surfaces
- 8sections in every API connectivity profile
Tools added by writing files
FAFO Core and Function Forge has a tool surface that grows constantly, and I decided nobody would hand-edit dispatch code to add a tool. Declarations live in YAML and the dispatch code is generated, so a new tool is a data change. The model-facing MCP gateway compiles YAML at build time, and input schemas come from the same metadata that drives routing, so they cannot drift from the implementation. The control plane compiles an auto-registration file into its dependency list and an extern-crate macro, and each function crate registers its execution handler and control target at link time.
That is how Function Forge adds a tool by writing files. The generator writes the gateway's definitions and the control plane's registration entry, and the next build turns them into routing, schemas and registration. Nothing registers at runtime. See Tools that build tools, under governance.
APIs as connectivity profiles
The API integration platform applies the same idea to external systems. Each API is a connectivity profile with a fixed set of sections, compiled into a generic runtime that is built once. See Closed by evidence.
One contract for producer and consumer
FAFOHive gets its media tools from a contracts crate that defines each tool's JSON Schema, examples and validation. The same crate compiles into the media service and the memory server, so the schema an agent sees and the schema the service enforces have one source.
I move integration work out of hand-written code into declarations the build compiles and checks, because that keeps a fast-growing tool estate consistent.
The techniques are standard Rust build scripts and procedural macros; my contribution is making them the single path for every tool.