Deploy your own MCP server

The catalog covers common APIs. For your own — an internal service, a vendor that isn't listed — point Statio at an OpenAPI spec and it generates, builds and deploys the MCP server for you.

What happens

TEXT

your OpenAPI spec
      │  fetch + hash
      ▼
   mcp-gen          generates an MCP server from the spec
      ▼
   docker build     an image, tagged with a version number
      ▼
   deploy           rolled out with an egress allowlist
      ▼
   tool discovery   tools registered so they can be granted

Each deploy produces a version. Versions are what rollback targets, so the image that ran last week is still there to return to.

Create the server

In the dashboard: Servers → New → From OpenAPI spec. Give it a name (this becomes the <server-name> in the connection URL) and the spec URL.

The spec must be reachable from Statio's build environment. A spec behind your VPN cannot be fetched — host it somewhere reachable, or paste it.

Deploy

Press Deploy. The build streams logs into the deployment view; a finished deploy reads succeeded.

If it fails, the logs say where: spec fetch, generation, build, or rollout. The most common failure is a spec that generates nothing useful — an OpenAPI document with no operations produces an MCP server with no tools.

Set the egress allowlist

A server Statio runs has no direct route to the internet. Before it can reach its upstream, add the host to Outbound Access:

TEXT

api.example.com     exactly that host
*.example.com       subdomains, NOT example.com itself

An empty list means the server can reach nothing. Blocked attempts are recorded under the same panel — a destination showing up there that should be allowed is one you have not added yet.

Add credentials and grant tools

Same as any server: the upstream credential goes in the vault, and tools are granted individually. See Credentials and Permissions.

Redeploying

Deploy again after the spec changes. Statio hashes the spec, so a deploy with no change short-circuits instead of rebuilding — use force when you want a rebuild anyway.

Rolling back

Pick a previous version and roll back. This redeploys the image already built for that version — no rebuild — so you return to exactly what ran before, rather than to whatever the spec says today.

Warning

Rollback returns the code, not the configuration. Credentials, grants and the egress allowlist are current-state and are not versioned with the image.

From CI

Everything above has an API, keyed to your organization rather than a browser session — see the Deploy API. A release from a pipeline is:

Bash

curl -X POST \
  -H "Authorization: Bearer $STATIO_KEY" \
  -H "Content-Type: application/json" \
  -H "X-Idempotency-Key: $(uuidgen)" \
  -d '{"force":false}' \
  https://api.statio.dev/v1/servers/$SERVER_ID/releases

That returns a deployment to poll until its status reads succeeded or failed, with /logs for the full output.

Note

Send X-Idempotency-Key on every release. A pipeline that times out and retries must not start a second build of the same thing.