If you've already developed a local API and paired it with an MCP (Model Contact Protocol) server, you're halfway there. Now it's time to move beyond local development and get your stack production-ready — starting with deploying your API and routing it through an API gateway.
In this post, we'll walk through how to deploy your API, connect it to your MCP server, and route everything through Zuplo, an API gateway that adds security, observability, and scalability to your backend. Our example uses Cloudflare Workers and a simple link-shortening service called Minilinks, but the same steps apply to nearly any stack.
Why Use an API Gateway with an MCP Server?
If you're exposing an API that will be consumed by an MCP server — especially one interfacing with LLMs or external clients — an API gateway becomes an essential piece of infrastructure.
Here’s why it matters:
Security: Gateways can enforce authentication, authorization, and IP
restrictions. This is critical when your API is publicly accessible or being called by third-party services.Rate Limiting: Protect your backend from abuse or accidental overload by
controlling how many requests each client can make. This is especially important in an LLM scenario where there may be no guardrails around how many requests it could make.Analytics and Monitoring: Gateways like Zuplo give you visibility into
traffic patterns, error rates, and response times, helping you debug issues and optimize performance.Request Validation: Incoming requests can be validated against an OpenAPI
spec, catching malformed payloads before they hit your backend.Centralized Policy Management: Instead of baking auth or CORS handling
into every endpoint, manage it globally and declaratively in one place.Versioning and Routing: Easily introduce new API versions, roll out
changes gradually, or route requests based on headers or paths.Scalability: Gateways are often deployed at the edge (as with Zuplo on
Cloudflare), reducing latency and distributing load closer to users.
In short, an API gateway helps move your project from “it works locally” to something robust, secure, and production-grade — which is exactly what you need when exposing real tools via an MCP server.
Prerequisites
Before following the steps in this guide, make sure you’ve already built the following:
- A working API with a defined set of HTTP endpoints (e.g. for creating users, links, retrieving data, etc.)
- An MCP server that defines tools which interact with your API
This post assumes that your MCP server includes a requestHandler
function that forwards tool requests to your API. It also assumes your server is configured to use an environment variable called API_URL
to determine the base URL of the API.
For example, your request handler might look something like this:
const baseUrl = process.env.API_URL ?? "http://localhost:8787";
// Use baseUrl to construct your outbound requests to the API
With this setup, switching your MCP server from a local API to a gateway-powered, deployed API is as simple as changing the API_URL
value in your environment.
Step 1: Deploy Your API
Your API can be hosted anywhere — Cloudflare, Vercel, Heroku, AWS, Azure, or even your own VPS. In this example, we’re deploying it using Cloudflare Workers with a D1 database, but you can follow similar steps regardless of your hosting provider.
After deploying, confirm that your API is live and connected to the database. If it returns a healthy response, you’re good to go.
Step 2: Set Up Your API Gateway with Zuplo
With your API live, it’s time to put an API gateway in front of it using Zuplo.
Start by creating a new project in Zuplo. Then, import your OpenAPI spec to quickly define all routes. This saves you from configuring endpoints manually. If you don't have an OpenAPI spec, that's fine too. You can create the routes for your API manually via the UI.
Next, get grab the URL of your hosted API. Open the routes.oas.json
file and update the servers
property to match your deployed API URL — whether it’s Cloudflare, Vercel, or another host. This ensures Zuplo forwards requests to the correct backend.
If you have any custom or recently added routes (like /health
), you can define them manually in the Zuplo UI if they're not in your OpenAPI spec.
Once your routes are ready, click Save and Deploy to push your configuration to Zuplo’s edge network.
Step 3: Reconfigure the MCP Server
Now that your API is live and gateway-enabled, it's time to point your MCP server to the gateway instead of the local instance.
The MCP server should be configured to use an environment variable called API_URL
, which defines the base URL your tools will use to interact with the API.
If you're using Claude Desktop, this can be set in the claude_desktop_config.json
file. Here's an example configuration:
{
"mcpServers": {
"minilinks": {
"command": "node",
"args": ["/Users/your-app/mcp-server/build/index.js"],
"env": {
"API_URL": "https://your-zuplo-url-goes-here.zuplo.dev"
},
"enabled": true
}
}
}
Once you've added or updated the API_URL
value in your config, restart Claude Desktop (or your MCP host) so it picks up the new environment variable.
From this point forward, any tool calls from the MCP server will be routed through the Zuplo gateway and forwarded to your deployed API.
Step 4: Test the End-to-End Flow
Use an MCP-compatible client like Claude or Cursor to test the setup.
The request should travel from the MCP client, through your MCP server, into the Zuplo gateway, and finally reach your deployed API — with a valid response returned.
To confirm everything is flowing properly, check the Zuplo analytics dashboard. You’ll see request logs, performance metrics, and top-used routes.
What Comes Next?
With your MCP server and API now connected via Zuplo, you’re set up to start adding all the elements you need to reliability and scale. Here are some next steps to consider:
- Enable API key authentication in Zuplo
- Set up rate limiting and abuse protection
- Add metering and billing support for monetization
- Host your MCP server so it's accessible by clients and users
This architecture is ideal for exposing toolsets to LLMs and other consumers securely and efficiently.
🎥 Don’t forget: the full video walkthrough is embedded above if you want to > see the process in action.
We'll be covering more of these topics in future posts.
Top comments (0)