MCP Foundry

Inspiration

APIs come with documentation, but AI assistants need tools they can actually call. Turning a large OpenAPI file into an MCP server by hand takes a lot of time. You have to understand the endpoints, create tool schemas, handle login details, write the server, and then test everything.

I built MCP Foundry to make that job easier, safer, and more visible. The basic workflow is:

Analyze → Review → Approve → Generate → Test → Repair

What it does

MCP Foundry turns a supported OpenAPI file into a tested TypeScript MCP server that runs locally.

The developer imports an OpenAPI file, reviews the suggested tools, authentication requirements, and safety information, and then approves the plan. MCP Foundry generates the server, builds it, checks the MCP connection, and saves the results. If a focused problem is found, Codex gets up to three attempts to repair it.

Once the checks pass, the generated STDIO server can be connected to Codex Desktop and used like any other MCP server.

How I built it

MCP Foundry is a TypeScript monorepo managed with pnpm. The interface uses React and Vite, while a local Node.js orchestrator manages each run.

The project includes:

• OpenAPI parsing and cleanup
• MCP tool planning and safety checks
• TypeScript STDIO server generation
• Build, schema, package, and MCP connection tests
• Focused repair attempts with saved logs and results
• A local dashboard for reviewing the whole process

After the developer approves the tool plan, MCP Foundry uses GPT-5.6 through the Codex SDK to write the MCP server inside an isolated workspace. Codex can also repair focused problems found during testing.

I also used Codex throughout development. It helped me move faster with implementation, tests, debugging, refactoring, and UI improvements. I kept the important decisions visible: the developer approves the tools, API keys stay in local environment variables, repairs are limited, and independent checks decide whether the generated package passes.

Challenges I ran into

OpenAPI files are not always clean

Real OpenAPI files can be incomplete, inconsistent, or written in different versions. I added normalization, useful error messages, small safe repairs, and a way to leave out operations that cannot be handled safely.

Authentication can get complicated

Some APIs mix API keys, bearer tokens, OAuth, and other login methods. The MVP supports API keys and bearer tokens. Unsupported operations are clearly reported and skipped instead of being generated incorrectly.

STDIO setup was easy to get wrong

A server could build correctly but still fail because Codex started it from the wrong folder. API base URLs and environment variables could also be configured incorrectly. I improved the setup instructions to include the exact command, file path, working directory, and environment settings.

Generated code still needs testing

AI-generated code can look correct while hiding runtime problems. MCP Foundry checks the build, MCP handshake, tool schemas, HTTP behavior, dependencies, secrets, and final package before reporting success.

Accomplishments that I am proud of

I am proud that MCP Foundry completes the full journey from an OpenAPI file to a working MCP tool inside Codex Desktop. It does not stop after generating code; it builds the server, verifies it, records every important event, and keeps the result available for review.

The workflow also keeps a human approval step before generation and limits automatic repairs instead of allowing an endless loop.

For the Art Institute of Chicago api demonstration, Codex successfully called 73 tools 30 quarantined from a server generated by MCP Foundry. This proved that the final package worked through a real local MCP connection.

What I learned

The biggest lesson was that a good AI developer tool needs more than a powerful model. It also needs clear limits, human decisions, proper tests, and results that people can inspect.

$$ \text{Trustworthy output} = \text{Generation} + \text{Testing} + \text{Evidence} $$

I also learned that converting OpenAPI to MCP is not just a code-generation problem. You still need to decide which endpoints should become tools, what they should be called, how authentication should work, and when the result is safe enough to use.

Codex worked best as a fast engineering partner inside a controlled process, not as a replacement for the process itself.

What's next for MCP Foundry

The next step is to support more APIs and make the generated tools even easier to understand and test. Planned improvements include:

• Streamable HTTP as an optional transport
• OAuth and additional authentication methods
• Multi-file OpenAPI documents and external references
• Better intent-based tool names and multi-step tools
• Stronger preflight checks before connecting a server to Codex
• Easier packaging and sharing of generated MCP servers

The long-term goal is to make MCP Foundry a dependable bridge between existing APIs and AI assistants, while keeping the process local, reviewable, and under the developer's control.

Built With

• codex
• gpt5.6
• node.js
• pnpm
• react
• typescript