Hi HN,
I’ve been building agentic workflows with Cursor and Claude Desktop, and I hit a massive friction point: securely exposing private, legacy REST APIs to my agents.
Whenever I wanted to give an agent access to a custom tool, I had to spend hours writing boilerplate Python or TypeScript to set up a Model Context Protocol (MCP) server, handle auth, and set up SSE connections. If I just dumped the raw Swagger/OpenAPI JSON into the context window, the LLM would get "choice paralysis" (schema noise) and hallucinate the wrong endpoints.
So, I built MCP Studio. It’s a visual proxy editor that lets you:
Upload an OpenAPI/Swagger spec.
Visually select (prune) only the 3-5 endpoints your agent actually needs (to save tokens and prevent hallucinations).
Instantly deploy a serverless SSE endpoint that you can drop directly into Cursor or Claude Desktop.
It also acts as a secure vault—you input your API keys into the UI, and it injects the auth headers server-side, meaning your raw keys never touch the local LLM context. I also recently added a PII Redaction toggle that masks emails and phone numbers at the proxy layer before they reach the LLM.
The stack is React (Vite) + Firebase + Node.js/Express on Render.
I'm currently in MVP mode and would love to hear how you all are currently handling MCP integrations and if a visual proxy layer solves a real pain point for your workflows.
https://eleayuen-png.github.io/OpenAPI-to-MCP-Converter-MVP/#/
This feels stronger than a simple OpenAPI-to-MCP converter. The real pain you’re naming is agent-tool exposure: how to let agents use private APIs without dumping huge schemas into context, leaking keys locally, or giving the model too many unsafe choices.
The pruning layer is probably the clearest wedge. Most MCP tooling talks about connecting tools, but your angle is more specific: expose only the few endpoints the agent actually needs, inject auth server-side, and reduce hallucination surface area. That makes it feel closer to secure agent infrastructure than a visual editor.
One thing I’d watch is the MCP Studio name. It explains the current workflow, but it may age narrow if this becomes a broader agent API control layer. A name like Exirra. com would carry the infrastructure direction better than something tied only to MCP setup.
spot on. minimizing that hallucination surface area by only exposing the necessary endpoints has been huge for our early users. mcp studio was a decent bootstrap name, but u are totally right that it boxes us in—exirra is a cool idea and going straight on the whiteboard.
That makes sense.
MCP Studio is useful for explaining the first wedge, but the product you’re describing is already moving into a bigger layer: agent API control, endpoint pruning, auth safety, and reducing tool-choice risk.
That is exactly why Exirra.com felt like a better fit. It gives the product room to become secure agent infrastructure without being tied too tightly to MCP as the category evolves.
I have access to Exirra.com, so if that direction is worth exploring seriously, happy to discuss privately and keep it simple.
You can connect with me here:
https://www.linkedin.com/in/aryan-y-0163b0278/