If you've been building MCP servers lately, you know the drill: define your tools in JSON, write handler functions, map parameters, validate inputs. It's not brain surgery—it's just tedious boilerplate that eats hours of your life. Developer kevintten10 got sick of it after building 10+ MCP servers and decided to ask a simple question: what if you could auto-generate an MCP server from an OpenAPI spec that's already sitting in your codebase?

The Problem Worth Solving

The promise of MCP is compelling—build one server, and any AI client can use it. But getting to that server still requires manual work for every API. Meanwhile, most existing REST APIs already have OpenAPI specs defining their endpoints, parameters, and schemas. Why write all that glue code twice? The solution: parse the spec, convert each endpoint to an MCP tool definition, route incoming calls to the actual API, return formatted responses. One-to-one mapping between OpenAPI endpoints and MCP tools.

How It Works

The implementation breaks into four logical pieces: parsing the OpenAPI 3.0 spec, converting endpoints to MCP tool definitions with JSON Schema parameters, building URLs with path parameter substitution, and executing requests through a REST client. The converter recursively copies schema structures from OpenAPI to standard JSON Schema for input validation. Error handling stays simple—send error messages back as text so the AI can parse them. The entire working implementation comes in at roughly 150 lines of Java using Spring Boot annotations.

What Actually Broke

The first surprise: not every OpenAPI spec is clean. Testing with GitHub API v3 revealed weird anyOf constructs that broke simple converters; Stripe's massive spec exposed too many endpoints for a single MCP server to handle gracefully. Real-world takeaway—auto-generation works best when you control the source spec, not someone else's messy definitions. The second issue surprised even the author: AI confusion at scale. With 10 tools, Claude Desktop performed great. At 30 tools, occasional mistakes appeared. At 50+ endpoints, wrong tool selection became frequent. The fix requires manually filtering which endpoints to expose rather than auto-converting everything. File uploads via multipart/form-data don't map cleanly to MCP's content type handling—the author simply skipped those endpoints for now. Authentication between the MCP server and underlying API also remains manual work; you still need API key interceptors or OAuth handlers configured separately.

Key Takeaways

  • Works best with OpenAPI 3.0 specs you control or can clean up first
  • Large APIs require endpoint filtering to avoid confusing AI clients
  • File upload endpoints need custom handling beyond the basic converter
  • Authentication must be wired manually regardless of auto-generation
  • Time savings are real: 20 tools that took ~5 hours now take 20 minutes total

The Bottom Line

This approach isn't a silver bullet for production-grade MCP APIs with custom business logic, but for internal services, rapid prototyping, or quickly adding AI integration to existing REST backends? It's hard to argue against. The code is readable, maintainable, and the author has open-sourced the full implementation in their Papers project on GitHub. Worth studying if you're serious about cutting MCP boilerplate.