Building MCP Studio: From OpenAPI to Agentic Magic (And the Bugs in Between)
If you've ever tried to give an AI agent (like Cursor, Cline, or Claude) access to a niche, private REST API, you know the pain. You end up spending your entire weekend writing custom boilerplate code just to set up a Model Context Protocol (MCP) server.
I got sick of the "glue code" crisis, so I decided to build MCP Studio—a SaaS tool that converts any OpenAPI/Swagger file into a secure, managed MCP gateway in under 60 seconds.
It sounds like a straightforward wrapper, right? Wrong. Building a stateful, interactive, cloud-synced proxy editor turned out to be an absolute rollercoaster. Here is the unvarnished journey of how it came to life, including every frustrating bug and "Aha!" moment.
The Spark: Context Bloat & The "Macro" Idea
The core hypothesis: giving an LLM a 150-endpoint Swagger file is a terrible idea. It blows up the context window, burns tokens, and causes the AI to hallucinate. I wanted to build a UI where developers could upload a JSON spec, visually check off only the endpoints they needed, and deploy it to a live Server-Sent Events (SSE) backend with zero-touch auth.
The stack: React (Vite) + Tailwind for the frontend, Firebase for state/auth, and a Node.js + Express backend running on Render.
Hurdle #1: The Black Screen of Death (Routing Nightmares)
Things started breaking almost immediately. I had my "Prune" page looking gorgeous, but when I tried to load it, the entire app crashed into a terrifying black screen.
The console screamed: Uncaught Error: You cannot render a <Router> inside another <Router>. I had accidentally wrapped my component in a MemoryRouter for testing, forgetting main.tsx was already managing the app with a HashRouter. A simple fix, but a stark reminder of how fragile React routing can be when you're moving fast.
Hurdle #2: State Amnesia (The "0 Endpoints Selected" Bug)
Because I was developing fast using cloud-based preview environments, I ran into module resolution errors and had to build "Mock Contexts" to keep the UI interactive.
This led to the ultimate nightmare. I enthusiastically clicked 5 different API endpoints, hit "Continue to Deploy", and read: "Ready to Deploy. You have selected 0 endpoints." My heart sank. Because I was using that "Mock Context" bridge, the selections were being saved to fake local memory instead of my global application state. I had to completely rip out the mock contexts and wire the components directly into Firebase's onSnapshot listeners, building a robust hydration sequence using useRef.
The "Aha!" Moment: Magic Suggest
While fighting state bugs, I was building the backend on Render and wanted a "Wow" factor. I integrated the Gemini 2.5 Flash API into my Node backend to build "Magic Suggest".
Instead of manually scrolling through hundreds of endpoints, the user clicks a button, the app sends the schema to Gemini, and the AI acts as an "Agent Architect"—automatically checking the 3-5 most useful endpoints. Seeing the checkboxes light up automatically on the frontend after a 2-second API call was pure magic. It validated the entire product.
Hurdle #3: The Rebel PII Redaction Toggle
I built a "PII Redaction" feature (masking emails/phones from the LLM) locked behind a $19/mo Pro tier. But there was a glaring UI bug: when I uploaded a fresh API schema, the PII toggle was showing up as ON (blue) by default, even for free users! If I toggled it on one project, it stayed on when I uploaded a completely different JSON file.
The fix required strict UI locking, forcing the cloud to reset piiMasking: false on every new upload, and adding a backend database listener to forcefully override state if a free user somehow bypassed the frontend.
Looking Back
Building MCP Studio was a crash course in managing complex, multi-page state and wrestling with context providers. There were moments where a simple checkbox not remaining checked made me want to pull my hair out.
But launching the app, uploading a massive 300-endpoint Swagger file, hitting "Magic Suggest", and instantly getting a secure, live SSE URL to drop into Cursor? Totally worth it.
The agentic era needs better plumbing, and I'm thrilled to have finally shipped some.
(Try the MVP: https://eleayuen-png.github.io/OpenAPI-to-MCP-Converter-MVP/)
This is such an important problem to solve. The context bloat issue you mentioned is real — I've seen agents completely fall apart when you throw a 100+ endpoint spec at them. The "Magic Suggest" approach of having an AI curate the relevant endpoints is clever.
One thing I've been thinking about from the other side: even with great MCP plumbing, individual agents still hit a wall when they need capabilities that aren't in their tool set at all. Your agent has perfect access to one API, but then the task requires calling a completely different service that nobody wrote a connector for. That's where the current "every agent is an island" model breaks down.
Curious — are you seeing users chain multiple MCP servers together? Like connecting their agent to 3-4 different API gateways at once? That seems like the natural next step but I imagine the context management gets hairy fast.
Spot on. The "every agent is an island" problem is absolutely the next massive bottleneck we're going to face as an ecosystem.
To answer your question: yes, people are definitely trying to chain multiple MCP servers. I'm seeing devs load up their Claude/Cursor configs with 4-5 different gateways at once (e.g., GitHub, Slack, Jira, plus a custom internal API). And exactly as you predicted, the context management gets incredibly hairy. Even if the connectors exist, dumping 5 distinct tool schemas into the system prompt causes the LLM to suffer from massive choice paralysis, and the hallucination rate spikes right back up.
That’s actually the exact reason I built the "Macro Tools" feature into MCP Studio. If you’re going to run multiple gateways simultaneously, you have to compress the surface area. Instead of giving the agent 5 raw endpoints to figure out, you bundle them into one chunky tool. Pruning and Macro bundling are the only ways multi-gateway setups survive the token limits.
As for the missing connector problem—where an agent just hits a wall because the capability isn't there—you hit the nail on the head. My long-term vision for the platform (once this MVP gets some real traction!) is a Community MCP Hub.
The idea is to have a marketplace where devs can publish their pruned, macro-bundled API setups. If your agent suddenly needs to hit a niche HR platform or a specific Stripe endpoint, you shouldn't have to write a custom proxy or build a connector from scratch—you just pull a vetted template from the Hub, drop in your API key, and keep building.
Really appreciate the insight. It's fascinating watching how quickly we are all hitting the exact same invisible walls with agent architecture!
agree, the core hypothesis lands. we hit the same wall building agent orchestration for 3 production codebases.
specific numbers: claude can hold 200k token context, but agent task-execution quality degrades non-linearly past ~30 endpoints. by 80, hallucination rate hits ~12% on routine calls (measured on a Stripe-like spec). pruning matters MORE than window size.
we ended up doing what MCP Studio does — but manually via redis SET per dispatch. cache holds only the endpoints for THIS task. ~80% reduction in inter-agent conflict, hallucination drops to 2% on pruned spec.
the macro/prune UI is the right wedge. tactical tip on the state amnesia: put endpoint selection in URL params, not context state. hard refresh stops losing selection. fragile combo: mock contexts + hot reload + nested routers.
curious about ur auth model — IAM-style for the generated gateway or per-tool API keys? 🤔
Man, seeing those specific hallucination numbers (12% dropping to 2%) is absolute gold. Thank you for sharing that! It completely validates the core thesis. Managing a manual Redis SET per dispatch sounds like a headache to maintain, but it proves exactly why endpoint pruning is way more critical than just relying on a massive 200k context window.
Appreciate the tactical tip on the URL params! That is a brilliant way to handle state, especially if I want to make configurations shareable later. I ended up ripping out the fragile mock contexts and hard-wiring the selections directly into Firebase onSnapshot listeners so the workspace state persists across devices, but I'm definitely logging the URL param idea for V2.
Regarding the auth model, it's a two-layer approach to keep the real credentials away from the LLM:
The Gateway Connection: When you hit deploy, MCP Studio provisions a unique Server-Sent Events (SSE) URL and generates a specific mcp_studio_xxx API key. You drop this into Cursor/Claude to secure the agent-to-gateway connection.
The Target API: Users securely store their per-tool credentials (Bearer, API Key, Basic) in their MCP Studio vault. When the LLM calls the proxy, the backend injects the real target keys into the headers server-side. The LLM never actually sees or holds your raw production keys.
Really appreciate you jumping in with that data. Would love to hear your thoughts if you get a chance to take the MVP for a spin!
"This is an incredible write-up and a brutal truth about the 'glue code' crisis. Giving an AI agent a massive, unpruned 150-endpoint Swagger file is the quickest way to burn through cash, inflate context windows, and trigger hallucinations.
The 'Magic Suggest' feature powered by Gemini to auto-prune schemas is pure genius. It fixes a huge bottleneck in the agentic plumbing era.
As someone running growth and architecture for AI platforms, I’ve seen so many developers hit a massive wall right after getting their MCP live: concurrency bottlenecks and API rate limits when scaling up their multi-agent workflows across different models.
To handle that heavy lifting on the backend, our engineering team relies heavily on pandasrouter. It essentially serves as an omni-router that aggregates enterprise-grade access to Qwen 3.7-Max, Claude 3.5 Sonnet, and Gemini under a single, highly resilient API key. Combining your MCP Studio for localized API pruning with a robust router like pandasrouter for global LLM routing is the ultimate stack for building production-grade AI agents.
Bookmarking your MVP link right now—can't wait to test it out inside Cursor!"
thanks for the kind words, giving an agent a raw 150-endpoint swagger is basically asking for it to hallucinate a destructive payload and nuke your db lol. u totally nailed the architecture vision though—pruning the context window is only the first step, because once those agents actually start executing at scale u absolutely need solid rate limit and concurrency management. pairing a localized, lean mcp schema with a heavy-duty global router like pandasrouter to handle model fallbacks and traffic spikes is a genuinely cool idea for a robust production stack, so definitely let me know how the workflow feels once u spin it up in cursor!
Elea, this is a strong build story because it shows the product is not just “OpenAPI to MCP.” The real value is controlled agent access to private APIs.
The endpoint pruning, Magic Suggest, managed SSE backend, auth layer, and PII redaction all point to a bigger category: secure API control for agents, not just MCP setup.
That is also why I’d be careful with MCP Studio as the long-term name. It explains the wedge, but the product already feels broader than “studio for MCP.” If this becomes the infrastructure layer that lets agents safely use private APIs, the name may start feeling too tied to the current protocol and setup workflow.
Exirra still feels like the stronger long-term direction to me because it can carry intelligence, control, and infrastructure without boxing the product into MCP only.
I would seriously decide the naming layer before more docs, users, GitHub references, and launch traffic attach to MCP Studio. This is the cleanest stage to fix it if you already feel the product is bigger than the wedge.