Hanzo
Cloud MCPplatform

post_v1_platform_sites_slug_releases

CreateRelease promotes a build output into a new immutable release WITHOUT serving it — the staged half of publishing, for when you want to check a release before it goes live. Answers 201.

CreateRelease promotes a build output into a new immutable release WITHOUT serving it — the staged half of publishing, for when you want to check a release before it goes live. Answers 201.

source is a path RELATIVE to your org's own storage space: the org segment is prepended server-side from the validated principal and the bucket is never in the request at all, so a server-side copy can only ever reach bytes your org already owns. The prefix is listed, content-addressed (SHA-256 over the sorted manifest of key/size/etag), and copied into an immutable <org>/.releases/<slug>/<id>/ prefix; the row is written LAST, so a partial copy is unreachable rather than merely unlikely. Re-publishing an unchanged source is idempotent BY CONSTRUCTION — same bytes, same id, no copy at all.

The source must contain index.html at its root and stay under the same file and byte caps an artifact deploy does (413 past them); a source that changes mid-copy is a 409 and the release is abandoned. Each publish also reclaims releases past the retention depth, so a site's release space stays bounded. This is the billable half — the hosting gate runs before any copy, and the debit lands once the release exists.

Scope: a validated principal is required (403 without one) and the site is resolved within that principal's org, so another tenant's slug is a 404.

Toolpost_v1_platform_sites_slug_releases
Doorhttps://api.hanzo.ai/v1/mcp
Methodtools/call (JSON-RPC 2.0)
Arguments2
OperationPOST /v1/platform/sites/{slug}/releases
Productplatform

Arguments

FieldTypeRequiredDefaultValuesDescription
slugstringSlug is the site to publish, from the path.
sourcestringSource is the build output to promote, as a path RELATIVE to your org's own storage space — never a URL and never a bucket. The org segment is prepended server-side from the validated principal, so the worst a hostile source can address is something your own org already owns.

tools/list declares a type and a description for each field and nothing further. A means neither the door nor that operation constrains the field.

Call it

A tools/call carries every argument in one flat object — nothing binds to a path or a query string. Nothing above is required, so every declared argument is shown rather than a guess at which matter.

curl -X POST https://api.hanzo.ai/v1/mcp \
  -H "Authorization: Bearer $HANZO_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
       "jsonrpc": "2.0",
       "id": 1,
       "method": "tools/call",
       "params": {
         "name": "post_v1_platform_sites_slug_releases",
         "arguments": {
           "slug": "<slug>",
           "source": "<source>"
         }
       }
     }'

Values are the operation's own defaults and enumerated values where it declares them, and a <placeholder> where neither source declares one. tools/list needs no credential; tools/call does — called without one the door answers HTTP 200 with a JSON-RPC result whose isError is set and whose text says what was missing. How to get a key →

The operation behind it

OperationRouteProductSummary
post_v1_platform_sites_slug_releasesPOST /v1/platform/sites/{slug}/releasesplatformPromotes a build output into a new immutable release WITHOUT serving it — the staged half…

The same capability over plain HTTP is in the platform API reference, on https://api.hanzo.ai.


All 755 tools · The door · API reference

Generated from tools/list on https://api.hanzo.ai/v1/mcp — 833 tools captured 2026-08-01, of which 755 are documented here (the operator surface is not published) (this build read the vendored copy; the door was unreachable).

How is this guide?

On this page