Collaboration proposal: consolidate OpenAPI-to-MCP code generation efforts

[quotentiroler]

Hi @sriaradhyula and team,

I'm the maintainer of mcp-generator-3.x, another Python-based OpenAPI-to-MCP code generator. I've been following your work and noticed we're solving the same core problem with complementary approaches. Rather than duplicating effort, I wanted to explore whether consolidation makes sense.

Where our projects overlap

Capability	openapi-mcp-codegen	mcp-generator-3.x
OpenAPI 3.0 / 3.1 parsing	✅	✅
Python MCP server generation	✅	✅
A2A agent generation	✅ (LangGraph + a2a-sdk)	✅ (lightweight a2a-sdk)
OpenAPI Overlay 1.0.0	✅ (LLM-powered + rule-based)	✅ (rule-based auto-generation)
Docker output	✅	✅
Auto-generated tests	✅ (eval suite)	✅ (pytest integration)

Where we differ (complementary strengths)

Your unique strengths:

• LangGraph React agent with full A2A server wrapper
• LangFuse-powered evaluation and tracing
• LLM-enhanced docstring generation (--enhance-docstring-with-llm)
• SLIM transport support
• A2A proxy (WebSocket upstream)
• Interactive eval mode with dataset builder
• Jinja2 template architecture

Our unique strengths:

• FastMCP 3.x native (composition, namespacing, streamable HTTP)
• Swagger 2.0 support alongside OpenAPI 3.0/3.1
• Modular sub-servers (one per tag, composed via mount())
• JWT / JWKS authentication middleware
• Full OAuth2 flow support
• Middleware stack (timing, logging, cache, auth)
• MCP Resources (GET endpoints as resource templates)
• MCP Apps (interactive UI: tables, charts, forms, detail views)
• Resumable event store
• BM25 search over tool catalog (for large APIs)
• Server registry with tag auto-discovery
• Built-in Python OpenAPI client generator (no Java/Node.js dependency)

The OpenAPI-to-MCP space is still small (6 projects total on GitHub), and I think users would benefit from one comprehensive solution rather than two partial ones.

Happy to jump on a call or continue the discussion here. What are your thoughts?

• Max (@quotentiroler)