0mcp

The operation and parameter controls stand out—it is much safer than exposing an entire API to an agent. How do you handle OpenAPI changes after an endpoint is live? Can teams review the diff and pin an older configuration before redeploying?

This one seems very useful, I will definitely try.

Honestly, we built this because we kept running into the same problem: we had APIs that worked perfectly, but making them usable by AI agents meant building and maintaining a whole separate MCP layer. So we thought — why not make the boring part ridiculously simple? That’s basically how 0mcp started. Import your API, pick what you want to expose, and get an MCP server you can actually use in production. We’re still building a lot around it, and I’d genuinely love feedback from people working with MCPs. If you try it, tell me what feels useful, what feels annoying, or what you think we’re missing. 🚀

This solves a real annoyance: most internal APIs are documented but not agent-callable, and hand-rolling MCP wrappers for each one is exactly the chore this kills. The OpenAPI-import + pick-your-operations flow is the right shape. One question: how are auth schemes handled on generated endpoints? Many internal APIs sit behind tokens or HMAC signing — being able to attach per-operation auth headers (or inject them at request time) is what decides whether this replaces hand-written wrappers.

For APIs with metered or billable operations, can automatic retries be disabled per tool, and can an idempotency key be passed through unchanged? A worked example would help teams avoid duplicate charges when an agent retries after a timeout.