Your APIs, as MCP tools
Letting AI agents use your API means running an MCP server — and building one for production means re-inventing auth, rate limits, and hosting. Zuplo turns your existing OpenAPI spec into a secure, edge-hosted MCP server, governed like the rest of your API.
API Routes
MCP Tools
Every MCP server in production today is also someone's auth and rate-limiting side project
Standing up an MCP server is the easy part. Making it production-grade — auth, rate limits, observability, deploy pipeline — is where most teams stall. The gateway already solved all of this for your APIs. MCP should inherit it.
Hand-rolling an MCP server in Python at 2am
Every product team writing a one-off MCP server. Half-implemented JSON-RPC. Auth handled with environment variables and good intentions. The agent works once, hangs the second time, and nobody knows why.
Two definitions, two truths
Your OpenAPI spec says one thing. The MCP tool schema says another. Drift compounds, the agent picks the wrong tool, the customer experience degrades, and the team blames the LLM.
Auth and rate limits, reinvented per agent
Each MCP server hand-codes its own auth, its own rate limits, its own logging. Every team's interpretation is slightly different. Compliance review is a sprint. The CISO is unhappy.
“Production” is a localhost stdio process
The MCP server runs on a developer's laptop because the team hasn't figured out remote hosting. Every customer demo is a local dev process. Real production for AI agents is still a wishlist item.
MCP that inherits your gateway, not invents a parallel one
OpenAPI is the source of truth
Mark operations with `x-zuplo-route.mcp` and Zuplo derives tool descriptions, parameters, and schemas from your existing OpenAPI definitions. No second schema to maintain. No drift between API and MCP.
Same policy stack as your APIs
OAuth, API keys, rate limits, prompt-injection detection, audit logs — anything you can attach to a normal route works on the MCP route. There is no separate MCP-only policy mechanism to learn or maintain.
Streamable HTTP at the edge
Zuplo runs the MCP server on the same 300+ edge POPs as your APIs. One POST endpoint, JSON-RPC 2.0, no stdio process to manage. Claude Desktop, Cursor, ChatGPT, MCP Inspector all connect to the same URL.
One handler, two flavors of tools
Use OpenAPI operations directly when REST is the right shape. Drop into TypeScript when the agent needs orchestration the API surface doesn't model — and call other gateway routes from inside the handler so each step runs through its own policies.
From OpenAPI spec to a live MCP server in five steps
No new service, no second schema, no JSON-RPC to hand-roll. Mark the operations you want, add one handler route, and deploy it the same way you ship the rest of your API.
- 1
Mark the operations you want agents to see
Add
x-zuplo-route.mcpto any OpenAPI operation —type: "tool"for actions,"resource"for reads,"prompt"for templates. Tool names and schemas come straight from the spec, so it stays the single source of truth.routes.oas.json - 2
Add the MCP server handler route
Point a
POST /mcproute atmcpServerHandlerand list the operationIds to expose. That one route is your whole MCP server.routes.oas.json - 3
Run it locally, then ship it
npm run devboots the gateway onlocalhost:9000(Route Designer on:9100). Deploy with the same GitOps flow as your API — push a branch for a preview URL, open a PR, merge — or runzuplo deploy.Terminal - 4
Your server is live at
/mcpOne Streamable HTTP endpoint —
https://<your-project>.zuplo.app/mcp— speaking JSON-RPC 2.0. No stdio process, no separate AI infrastructure. Every auth, rate-limit, and audit policy already on your API applies here too. - 5
Connect Claude, Cursor, or ChatGPT
Point any Streamable-HTTP MCP client at your
/mcpURL and it discovers your tools automatically. Claude Desktop and Claude Code, Cursor, ChatGPT (as a custom connector), VS Code, and MCP Inspector all connect the same way.
Want the full walkthrough? Read the MCP quickstart.
Production MCP, not a Python prototype
Tools, resources, and prompts from one handler
The `mcpServerHandler` exposes all three MCP primitives. Mark a GET route as a resource and clients see it via `resources/list` / `resources/read`. Mark an action as a tool and clients see it via `tools/list` / `tools/call`. Prompts work the same way. One handler, three discovery paths.
Custom tools when OpenAPI isn't enough
Write a TypeScript handler, register it as an MCP tool, orchestrate multi-step workflows by calling other gateway routes via `context.invokeRoute(...)`. Each invoked route runs through its own policies. Build agents that compose your existing API surface without leaving the gateway.
MCP-aware OAuth resource metadata
Set `oAuthResourceMetadataEnabled: true` and Zuplo serves the MCP-spec-compliant OAuth resource metadata clients need to discover your auth server. No custom proxy code. No "works in Cursor but not Claude Desktop" debugging — auth follows the spec.
Govern many MCP servers with MCP Gateway
When the org grows past one MCP server, the MCP Gateway adds auth translation, virtual MCP servers with team-scoped tool access, security policies across all MCP traffic, and observability into every tool invocation — including third-party MCP servers your agents reach.
Running many MCP servers? Govern them behind one gateway.
The MCP Gateway fronts your servers and third-party ones alike — one OAuth-protected route per upstream, team-scoped tool access, and audit across every tool call.
What teams use this for
“We want Claude to read order data and create support tickets.”
Mark `GET /orders/{id}` as `mcp: { type: "resource" }`. Mark `POST /tickets` as `mcp: { type: "tool" }`. Register both in the MCP handler. Point Claude Desktop at your `/mcp` URL. Done — same OpenAPI, two new MCP capabilities, full audit log on every invocation.
“We need to expose our API to ChatGPT and Cursor users.”
One Zuplo MCP server, one URL, every Streamable-HTTP-capable MCP client connects. ChatGPT (as a custom connector), Cursor, Claude Desktop, MCP Inspector — same endpoint, same auth, same rate limits.
“The agent needs a multi-step workflow our REST API doesn't model.”
Write a TypeScript handler. Mark it `mcp: { type: "tool" }`. Inside, call other gateway routes via `context.invokeRoute(...)` — search products, check inventory, calculate shipping, create order — each one running through its own policies. The agent sees one tool; you keep API hygiene.
“Compliance wants every MCP tool call audited.”
MCP requests pass through the same policy stack as everything else, so attach the same audit-log policy. Every `tools/call` lands in your SIEM with caller identity, tool name, parameters, and response code. No separate logging pipeline for AI traffic.
Frequently Asked Questions
Common questions about hosting MCP servers on Zuplo.
Stop hand-rolling MCP servers
Free Zuplo project, mark a few OpenAPI operations, ship a real edge-deployed MCP server with auth, rate limits, and audit logs in an afternoon.