Most APIs Already Have OpenAPI Specs. So, Why Are We Still Building MCP Servers By Hand?
A few weeks ago, I started experimenting with MCP servers.
The idea seemed simple.
Most of the APIs I wanted to use already had OpenAPI specifications. In theory, that should make exposing them to AI agents straightforward.
In practice, it wasn't.
Every API required writing MCP wrappers, defining tools, mapping schemas, handling updates, and maintaining yet another layer of infrastructure.
The strange part was that the API definitions already existed.
The information needed to create the MCP server was already there.
Yet I kept repeating the same work over and over again.
After doing this a few times, I started wondering:
Why am I manually building MCP servers from specifications that are already machine-readable?
That question eventually became MCPForge.
The goal is simple:
Take an OpenAPI specification and turn it into a working MCP server in minutes.
No manual tool definitions.
No wrapper boilerplate.
No repetitive setup.
I'm currently focused on:
• OpenAPI and Swagger imports
• Hosted MCP servers
• Automatic synchronization
• Usage analytics
• Authentication proxying
MCP is still early, which makes this a good time to experiment.
I'm sharing progress publicly and would love feedback from anyone building with Claude, Cursor, OpenAI, or other AI agents.
What has been the most frustrating part of working with MCP so far?
The gap between machine readable and actually usable is wider than it looks from the outside, and you have described that really well here.
Curious how you are handling versioning when an upstream API updates its spec. Does MCPForge detect the drift automatically or is that still a manual trigger?
MCP tooling is going to matter a lot over the next 12 months. Good timing to be building this.
This is exactly the kind of thing that looks simple until you’ve done it a few times.
What’s interesting is you’re not really building “MCP servers” — you’re building the translation layer between existing specs and agent-ready tools.
Curious if the harder part ends up being generation, or keeping it stable as APIs change underneath.
I started thinking the hard problem was the conversion from OpenAPI to MCP.
After building it and talking to engineers, I'd say that's probably only 20% of the problem.
API changes, versioning, and schema drift are definitely real challenges, but the biggest concerns I've heard are around governance:
Which tools should agents be allowed to call?
How do you handle refunds, deletes, or admin actions?
Who approved a sensitive action?
How do you audit what happened later?
That's actually pushing the product more toward MCP operations and governance than pure MCP generation.
Yeah, that split makes sense.
In practice, governance usually gets tricky when you have both human-in-the-loop actions and fully automated ones in the same surface.
Are you planning to keep those strictly separated in the UX, or unify them under the same execution model with different permission levels?
I'm leaning toward keeping it unified.
My current thinking is that every tool call should go through the same execution path, with different policies applied depending on risk.
A read-only search tool can run automatically, while a refund or delete action might need approval.
What's interesting is that two companies can expose the same MCP tool and still have completely different governance requirements around it.
That's exactly the part I'd be careful with.
I don't think the interesting question is the governance model itself.
I think it's the decision sitting underneath it.
I'd be careful unpacking that casually in a thread.
If you'd like the tighter version, drop your email and I'll put it together properly.
I'd be interested in hearing your take.
My account is still new, so I can't post links yet, but I'd genuinely appreciate the feedback.
What do you think the decision underneath it actually is?
I can send it over if you want — drop your email here.
Unfortunately, I don't have that option yet. My account is still new, and Indie Hackers blocks me from posting links or contact details.
Sent you a note at kamolc4@gmail.com.
I think the decision matters more than the implementation discussion right now.