---
title: "Meet the Zuplo MCP Server"
description: "The Zuplo MCP server exposes the full Developer API as tools so Claude Code, Cursor, or any MCP client can manage deployments, keys, and domains."
canonicalUrl: "https://zuplo.com/blog/2026/05/20/introducing-the-zuplo-mcp-server"
pageType: "blog"
date: "2026-05-20"
authors: "martyn"
tags: "Model Context Protocol, ai-agents, product"
image: "https://zuplo.com/og?text=Introducing%20the%20Zuplo%20MCP%20Server"
---
The Zuplo MCP server is now live at `https://dev.zuplo.com/mcp`, making your
Zuplo account operable from any MCP client. It exposes the full
[Zuplo Developer API](https://dev.zuplo.com) as Model Context Protocol tools, so
an agent can list deployments, roll API keys, add a custom domain, query audit
logs, and run anything else the Developer API supports in a single authenticated
session.
## What the Zuplo MCP server exposes
The tool catalog is generated directly from the Developer API's OpenAPI spec.
Every endpoint the API ships becomes an MCP tool the moment it deploys, with no
hand-maintained tool definitions falling out of sync.
| Area | What agents can do |
| ----------------- | ----------------------------------------------------------------------------------------- |
| Accounts | List accounts and identify the caller (`WhoAmI`) |
| Projects | List projects and environments in an account |
| Deployments | List, read, redeploy, and delete deployments. Upload sources and check deployment status |
| API Key Buckets | Create, list, read, update, and delete API key buckets |
| API Key Consumers | Create, list, read, update, delete, and roll keys for consumers. Manage consumer managers |
| API Keys | Create (single or bulk), list, read, update, and delete keys for a consumer |
| Custom Domains | Create, list, update, and delete custom domains |
| Client mTLS CAs | Create, list, update, and delete client mTLS CA certificates |
| Tunnels | Create, list, read, update, and delete tunnels. Configure and inspect tunneled services |
| Variables | Create and update environment variables on a project branch |
| Audit Logs | Query audit logs with filtering and pagination |
| Analytics | Get recent calls and request statistics by status code for a deployment |
If your team already operates Zuplo through the Developer API, the MCP server
gives you the same primitives with an agent on the other end.
## Authenticate the Zuplo MCP server with an API key
The server uses the same API keys as the Developer API. Create one in the Zuplo
Portal under
[**Account Settings → API Keys**](https://portal.zuplo.com/+/account/settings/api-keys),
then pass it as a bearer token:
```http
Authorization: Bearer
```
The key's permissions determine which accounts, projects, and operations show up
as tools at runtime, so the agent only ever sees the surface you've granted.
Scope it tightly: a key with full account access lets the agent do anything you
can do, which is the same trust model as API automation but with a much chattier
client on the other end.
Reusing your personal full-access API key for an agent session. Create a
dedicated, scoped key per agent or per project. Treat it like a production
credential, because it is one.
## Add the Zuplo MCP server to your client
The server speaks MCP over HTTP with bearer auth, so any client that supports
custom headers works: Claude Code, Cursor, VS Code, or anything else MCP-aware.
Point your client at `https://dev.zuplo.com/mcp` and pass the bearer token in
the `Authorization` header. Keep the key out of source control by storing it in
an environment variable or your client's secret store.
## Example prompts the Zuplo MCP server handles
Once connected, you can drive Zuplo from natural-language prompts:
- _"List all deployments in the `production` environment of project `my-api`."_
- _"Create a new API key consumer named `acme-corp` and generate a key that
expires in 30 days."_
- _"Roll all API keys for consumer `legacy-client` and set a 7-day expiration on
the old key."_
- _"Show me the request stats by status code for the latest deployment over the
last 24 hours."_
- _"Add `api.example.com` as a custom domain on the `production` environment."_
- _"Set the environment variable `LOG_LEVEL` to `debug` on the `main` branch."_
The agent picks the tools, fills in parameters from context, and reports back.
The "open the portal, find the project, click into the right environment"
friction disappears, and for operations you'd normally script, the script writes
itself.
Pair this with
[Zuplo's Agent Skills](https://zuplo.com/docs/build-with-ai#agent-skills) and
you get the combination that earns its place. The four skills (`zuplo-guide`,
`zuplo-monetization`, `zuplo-cli`, and `zudoku-guide`) give your agent grounded
context: how the request pipeline works, how policies compose, how monetization
plans hang together, how the CLI maps to the platform.
This server gives it the surface to act on that knowledge. An agent that can
both look up how a policy works and apply it to a route is a different class of
tool.
## Where this fits
Alongside Zuplo's Agent Skills, this completes the toolkit: the skills teach an
agent how Zuplo works, this server lets it act. We expect most teams running
Zuplo from an agent to install both.
It also tracks our broader thinking on MCP: last year we
[wrote about MCP's first year](/blog/2025/11/24/one-year-of-mcp) and
[the CLI vs MCP question](/blog/2026/01/14/cli-or-mcp). This release is the
practical answer for Zuplo: anything you can do against the Developer API, you
can now ask an agent to do.
The [Zuplo MCP Server](https://zuplo.com/docs/build-with-ai#zuplo-mcp-server) is
ready to use. Create an API key, drop the snippet into your client of choice,
and start asking your agent to do the gateway work you'd usually click through.