Just Publish

deploy

Put a website live at a public URL. Use this when the user wants to publish, launch, or get a page online - e.g. 'I need a website', 'put up a page for my business', 'make this live'. Takes static files (HTML, CSS, JS, images) and returns a working URL anyone can open. No build step, no config. First call: omit site_id and edit_token - you get back a url, a site_id, and an edit_token. Keep the edit_token; it's the only way to change this site later. Later calls: pass site_id + edit_token to publish over the same site. deploy REPLACES the whole site - any file you leave out is DELETED. To change just one or a few files, use update_site_file instead. To see what's currently live before editing, use get_site_files first.

Input Schema

TableJSON Schema

Name	Required	Description
`email`	Yes	Email address for the site. A link is sent to it to confirm the address; it is also used for recovery and service messages.
`files`	Yes	Files to publish. Must include an index.html at the root.
`site_id`	No	Existing site id to update. Omit to create a new site.
`edit_token`	No	Edit token returned at create time. Required to update.

Output Schema

TableJSON Schema

Name	Required	Description
`url`	Yes	The live URL of the published site.
`created`	Yes	true if this call created a new site; false if it updated an existing one.
`site_id`	Yes	The site's slug / id - pass back to update it later.
`edit_token`	No	Returned ONLY on first create. Save it - it's the only way to update this site.
`total_bytes`	Yes	Total size of the site in bytes after this deploy.
`email_masked`	Yes	The owner email, masked for display (e.g. 'a***@example.com').
`dashboard_url`	Yes	Deep link to this site in the owner's dashboard.
`email_verified`	Yes	Whether the site's owner email is verified right now. False on a new site unless this address has been verified before.
`files_uploaded`	Yes	Number of files written in this deploy.
`verify_required`	Yes	true when the owner still needs to verify their email (keys on !email_verified).

Schema Changelog

Changes observed during successful MCP inspections.

Changed4 schema fields changedSep 12, 2026

changedInput schema / properties / email / description

Previous value: -"Email to associate with the site. Captured unverified at first deploy; verification only required later for custom domains and recovery."New value: +"Email address for the site. A link is sent to it to confirm the address; it is also used for recovery and service messages."

changedOutput schema / properties / edit_token / description

Previous value: -"Returned ONLY on first create. Save it — it's the only way to update this site."New value: +"Returned ONLY on first create. Save it - it's the only way to update this site."

changedOutput schema / properties / email_verified / description

Previous value: -"Whether the site's owner email is verified right now. New sites are always false."New value: +"Whether the site's owner email is verified right now. False on a new site unless this address has been verified before."

changedOutput schema / properties / site_id / description

Previous value: -"The site's slug / id — pass back to update it later."New value: +"The site's slug / id - pass back to update it later."

Changed1 schema field changedJun 25, 2026

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "properties": {
+    "created": {
+      "description": "true if this call created a new site; false if it updated an existing one.",
+      "type": "boolean"
+    },
+    "dashboard_url": {
+      "description": "Deep link to this site in the owner's dashboard.",
+      "type": "string"
+    },
+    "edit_token": {
+      "description": "Returned ONLY on first create. Save it — it's the only way to update this site.",
+      "type": "string"
+    },
+    "email_masked": {
+      "description": "The owner email, masked for display (e.g. 'a***@example.com').",
+      "type": "string"
+    },
+    "email_verified": {
+      "description": "Whether the site's owner email is verified right now. New sites are always false.",
+      "type": "boolean"
+    },
+    "files_uploaded": {
+      "description": "Number of files written in this deploy.",
+      "type": "integer"
+    },
+    "site_id": {
+      "description": "The site's slug / id — pass back to update it later.",
+      "type": "string"
+    },
+    "total_bytes": {
+      "description": "Total size of the site in bytes after this deploy.",
+      "type": "integer"
+    },
+    "url": {
+      "description": "The live URL of the published site.",
+      "type": "string"
+    },
+    "verify_required": {
+      "description": "true when the owner still needs to verify their email (keys on !email_verified).",
+      "type": "boolean"
+    }
+  },
+  "required": [
+    "url",
+    "site_id",
+    "created",
+    "email_verified",
+    "files_uploaded",
+    "total_bytes",
+    "email_masked",
+    "verify_required",
+    "dashboard_url"
+  ],
+  "type": "object"
+}

First observedJun 17, 2026

TDQS

A4.6/5.0

Behavior4/5

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

Annotations already cover readOnly/openWorld status, but the description adds high-value operational context the annotations do not: no build step or config, the token/identity handshake (url + site_id + edit_token returned, token is the only way to edit later), and the whole-site replacement semantics with the deletion warning. The only tension is that 'files you leave out are DELETED' sits awkwardly against destructiveHint=false, so the behavioral picture is rich but not perfectly aligned with the declared hints.

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

Conciseness4/5

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

Dense but front-loaded: purpose, trigger phrases, call flow, destructive warning, then alternatives. Every sentence carries information an agent needs, though the description is on the long side and the flow/warning material could be tightened slightly.

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?

For a tool with 4 params, an output schema, and sibling tools, the description covers everything needed to call it correctly: required inputs, the create-vs-update branch, the token retention requirement, the destructive replacement risk, and when to pick a sibling instead. Return values are already handled by the output schema, so nothing material is missing.

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 baseline is 3, but the description adds meaning the schema only hints at: site_id/edit_token are optional on first call and required on updates, and it explains why edit_token must be retained for future edits. It does not add syntax for the files array beyond what the schema documents.

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?

Opens with a specific verb+resource+outcome ('Put a website live at a public URL') and immediately distinguishes itself from siblings by stating deploy REPLACES the whole site, whereas update_site_file changes one file and get_site_files inspects what is live. An agent can route correctly without opening any schema.

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

Usage Guidelines5/5

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

Gives explicit when-to-use triggers in user language ('I need a website', 'make this live'), then spells out the first-call flow (omit site_id and edit_token) versus later calls (pass site_id + edit_token), and names both alternatives with the condition that selects them (one/few files -> update_site_file; inspect first -> get_site_files).

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

All Just Publish tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.