Skip to main content
Glama

ShipStatic

by com.shipstatic

Deploy Static Site

deployments_upload

Deploy a static site to a live URL — free, no account or API key required.

File content is plain text by default. Pass HTML/CSS/JS/JSON/SVG/etc. directly in each file's content as a regular string. Only set encoding: "base64" per-file for binary content (images, fonts) — do not base64-encode text.

Returns the live URL. Without a connected account, the response also includes a claim URL (the site expires in 3 days unless claimed) — always show both to the user. To make the site private, pass password; always show the password to the user if you set one.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
ttlNoSeconds until this deployment expires and the platform reclaims it; omit for one that never does. Only for authenticated deploys — an anonymous deployment already expires on the platform's schedule, and a requested ttl on one is refused. A deployment carrying a ttl cannot be linked to a custom domain: deploy without one if the site needs a domain.
filesYesFiles that make up the site. The site root is implied by these paths.
labelsNoLabels for organizing deployments (e.g. ["production", "v1.2"]). Lowercase, 3-25 chars, allows . _ - separators. Up to 10.
passwordNoOptional password to gate the deployment behind an unlock prompt (6–128 characters; whitespace significant). Visitors must enter this password before viewing the site, including on any custom domains pointing at it.
idempotencyKeyNoMakes this deploy replayable instead of repeatable. A deploy is not naturally idempotent: if a call times out you cannot tell "it never landed" from "it landed and the response was lost", and retrying creates a second deployment. Send the same key on the retry and the original deployment is replayed instead (within 24 hours). Key the ATTEMPT — a run id, a commit sha, a uuid minted before the first try — never one minted fresh on each retry, which would defeat the point.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
urlYesFull URL to the live deployment.
viaYesOrigin tag for analytics (e.g. "gpt", "mcp", "cli", "web"). Null on legacy deployments uploaded before tagging existed.
sizeYesTotal deployment size in bytes.
claimNoOne-time URL that claims this anonymous deployment to a free account, making it permanent. Only present on anonymous deploys — absent when the deploy was made with a connected account.
filesYesNumber of files in the deployment.
configYesTrue if the deployment includes a `ship.json` routing config.
labelsYesLabels attached to the deployment.
statusYesDeployment lifecycle state. `success` means the site is live.
createdYesUnix timestamp (seconds) when the deployment was created.
expiresYesUnix timestamp (seconds) when the deployment expires; null when permanent. Anonymous deploys through the hosted MCP expire 3 days after creation unless claimed; an authenticated deploy carries one only when it requested a ttl.
passwordYesTrue if the deployment is password-protected.
deploymentYesDeployment hostname, e.g. "happy-cat-abc1234.shipstatic.com".
screenshotYesFull URL to the deployment screenshot. Captured asynchronously after deploy; the URL is returned immediately but the image may take a few seconds to become available.

TDQS

A4.7/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Beyond the annotations' read/write hints, the description discloses important behaviors: anonymous deployments expire in 3 days unless claimed, the response includes a claim URL, and users must always be shown both the live URL and any password set. It also clarifies encoding behavior prominently, which prevents a common misuse. No annotation contradiction is present.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is compact and front-loaded: the core purpose is in the first sentence, followed by the most likely failure point (encoding), then response behavior. Every sentence earns its place and no content is redundant with the schema.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the rich 100%-covered input schema and an output schema, the description only needs to supply behavioral and situational context. It does so effectively, covering anonymous expiry, claim URLs, password handling, and encoding guidance. Nothing essential is missing for an agent to invoke the tool correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the parameters are already well documented. The description adds practical semantics on top: plain text by default, base64 only for binary files, and the reminder to always show the password to the user. This is helpful guidance beyond the schema, though much of the detailed parameter meaning still lives in the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific verb and resource: 'Deploy a static site to a live URL'. It also immediately distinguishes itself from the domain tools and other deployment tools by stating what it produces (a live URL) and by noting that no account or API key is required. This leaves little ambiguity about what the tool does.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives clear situational context: use this to deploy static sites, no account required, and it explains what happens without a connected account (claim URL, expiry). It does not explicitly name alternatives among the sibling deployment tools, such as deployments_set for updating settings, so it stops short of a 5.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All ShipStatic toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.2/5.0
Disambiguation5/5

Deployment tools and domain tools are cleanly separated by resource prefix, and each tool targets a distinct action (list/get/upload/delete/set vs validate/set/records/verify). The few related domain tools—dns, records, share, verify—have clear boundaries around provider lookup, record display, shareable links, and verification triggering.

Naming Consistency4/5

Tool names consistently follow a resource_action pattern: deployments_* and domains_* with clear verbs. The only deviation is whoami, which is a conventional standalone name but does not follow the noun_verb structure; this is a minor exception.

Tool Count5/5

Fifteen tools is at the upper end of the ideal range but every tool serves a distinct purpose within the static-hosting and custom-domain lifecycle. There is no apparent redundancy or bloat.

Completeness5/5

The deployment surface covers upload, read, list, update labels, and delete, while the domain surface covers validation, creation/update, details, listing, DNS records, verification, sharing, and deletion. The account check via whoami rounds out the lifecycle with no obvious dead ends.

Resources