NitroForge is an MCP server that builds other MCP servers. Point it at an OpenAPI spec, and it generates a working NitroStack server, complete with typed tools, Zod schemas, and widget bindings, then runs that server through its own verification pipeline before anyone touches the code.
What this enables
- Converts an OpenAPI spec into typed MCP tools without the model inventing field names or parameter types
- Clusters related endpoints into tools with their own schema, example, and widget binding
- Runs generated code through type check, build, boot, and a replay against expected responses before it ships
- Exposes every stage of generation and verification as calls over the MCP protocol itself
- Deploys the resulting server to NitroCloud and pairs it with NitroChat for a usable front end
Why generating an MCP server is harder than it sounds
Turning an API into an AI-callable tool sounds simple until you ask a model to do the naming. A model can read an OpenAPI spec and describe what an endpoint does, but if it also writes the schema by hand, it can quietly invent a field, get a type wrong, or drop a required parameter. That kind of error is easy to miss in a demo and expensive in production, because the model is the one deciding what a "customer" object looks like instead of the API's own contract.
The harder version of the problem shows up once you try to verify the output. A generated MCP server needs to type check, compile, and actually boot before it is safe to call. Doing that by hand for every generated project does not scale, and doing it silently defeats the point of building on MCP, where a client should be able to inspect what a server can do.
Keeping generation deterministic, judgment thin
NitroForge's design choice is to split the pipeline into two layers with very different trust levels. The schema for each tool is derived directly from the OpenAPI spec's own parameters and response shapes, using the spec parser and Zod, not written or paraphrased by a model. In one generated file, three tools each carry their own schema, example payload, and widget binding, all produced from the spec rather than typed by hand.
The model's job sits on top of that deterministic layer. It names a tool, writes the description another AI client will read when deciding whether to call it, and picks a widget, a data table for a list response, a stat card for a single number. None of those choices exist in the source spec. They are judgment calls layered onto a foundation the model cannot corrupt, because the schema underneath already came from the spec before the model saw it.
That is also why NitroForge is a generator and not a proxy. A proxy would expose the same endpoints and pass parameters through unchanged. NitroForge renames, describes, and re-groups endpoints into tools that make sense to another model, while leaving the underlying contract exactly as the spec defined it.
Verifying what it just built
Generated code only ships after it survives its own pipeline: type check, build, boot, and a live replay of each tool against its expected response. In one walkthrough, type checking passed against the real TypeScript compiler in about five seconds, and the build completed in roughly four. When the boot step timed out on that run, the cause traced back to the machine, not the generated code, since the same code had already compiled cleanly. That distinction, a platform issue caught live versus a defect in the generated project, is the kind of detail that only shows up once you actually try to run what you generated instead of stopping at "it compiled."
The repository's own status reflects this staged approach. Ingest and planning, turning the spec into an endpoint graph and a tool surface, are the parts that are fully built and tested, with the parser and planner services passing their test suites. The emit-and-verify and deployment stages have their contracts frozen and ready to build against, which is the honest way to describe a project mid-build rather than calling every stage finished.
Where NitroStack fits
NitroForge is itself a NitroStack MCP server, built with the NitroStack SDK in TypeScript. It uses the SDK's tool and schema patterns to expose its own pipeline, parsing a spec, planning a tool surface, generating code, as callable MCP tools rather than a black-box CLI step. That is a deliberate choice: instead of hiding the generation process, NitroForge makes each phase inspectable by any MCP client, including NitroStudio during development.
For the output side, the generated servers are deployed through NitroCloud and paired with NitroChat, giving a generated project a production hosting path and a usable conversational front end without a separate deployment setup for each one.
The pattern worth reusing
The reusable idea here is not "AI writes your integration code." It is the boundary between what a spec can prove and what a model has to judge. Anything that could be wrong by hallucination, a field name, a type, a required parameter, stays in code the model never touches. Anything that requires judgment, naming a tool well enough for another model to choose it correctly, picking the right widget for a response shape, sits in a thin layer that gets checked before it ships. That split is what makes an MCP server generator trustworthy enough to run unattended instead of something you have to review line by line.
Explore the NitroForge source and its verification contracts on GitHub, or start building your own OpenAPI-to-MCP pipeline with the NitroStack SDK.