Skip to main content
Glama
Sign In

3dCMS

by info.3dcms
OverviewDiscussionsAdmin

Publish a 3dCMS scene

publish_scene
DestructiveIdempotent

Use this when the user wants their scene live as a public link to share, or to update one already live. Publish a saved scene to a PUBLIC, shareable URL so anyone can view it in 3D in a browser — no login required. PUBLISHING IS PARTLY IRREVERSIBLE: the URL is submitted to search engines (IndexNow) the moment it goes live, so it may appear in results even after a takedown. ALWAYS confirm with the user first, then call with confirm:true — without it this tool publishes nothing and returns what WOULD happen. Returns the public site URL plus a per-page URL list. Re-publishing the SAME scene updates its existing public site (the URL stays stable).

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "sceneId": "<sceneId>"
    },
    "name": "publish_scene"
  }
}

Input Schema

NameRequiredDescriptionDefault
listedNofalse publishes UNLISTED: reachable by its link, but kept off Explore and your creator profile, marked noindex and not submitted to search engines. Omit for a normal listed publish.
confirmNoMust be exactly true to publish. Omit / false to get a needsConfirm summary for the user.
sceneIdYesScene id from list_scenes.
siteSlugNoPublish onto one of YOUR existing sites by its slug (the part after /sites/ in its URL) instead of this scene's own. When that site shows another scene, the first call answers willReplace: name the site to the user and call again on a yes with confirmReplace set to willReplace.replaceToken. Later publishes of this scene go to that site.
shortLinkNotrue also returns shortUrl, a short 3dcms.info/s/<code> link to the site (one stable code per site), for sharing and QR codes. Without confirm, a scene whose site is already live gets its shortUrl at once, no republish.
confirmReplaceNoOnly after a reply with needsConfirm and willReplace, and the user's yes naming that site: pass willReplace.replaceToken exactly when it has one (siteSlug publishes), otherwise true.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • changedInput schema / properties / shortLink / description
      Previous value: -"true also returns shortUrl, a short 3dcms.info/s/<code> link to the site (one stable code per site), for sharing and QR codes."New value: +"true also returns shortUrl, a short 3dcms.info/s/<code> link to the site (one stable code per site), for sharing and QR codes. Without confirm, a scene whose site is already live gets its shortUrl at once, no republish."
    • changedInput schema / properties / siteSlug / description
      Previous value: -"Publish onto one of YOUR existing sites by its slug (the part after /sites/ in its URL) instead of this scene's own. When that site shows another scene, the first call answers willReplace: name the site to the user and call again with confirmReplace:true on a yes. Later publishes of this scene go to that site."New value: +"Publish onto one of YOUR existing sites by its slug (the part after /sites/ in its URL) instead of this scene's own. When that site shows another scene, the first call answers willReplace: name the site to the user and call again on a yes with confirmReplace set to willReplace.replaceToken. Later publishes of this scene go to that site."
  2. Changed2 schema fields changed
    • changedInput schema / properties / confirmReplace / description
      Previous value: -"Only after a reply with needsConfirm and willReplace: exactly true replaces that live site with this scene. Ask the user first, naming the site."New value: +"Only after a reply with needsConfirm and willReplace, and the user's yes naming that site: pass willReplace.replaceToken exactly when it has one (siteSlug publishes), otherwise true."
    • changedInput schema / properties / confirmReplace / type
      Previous value: -"boolean"New value: +[
+  "boolean",
+  "string"
+]
  3. Changed2 schema fields changed
    • addedInput schema / properties / shortLink
      Added value: +{
+  "description": "true also returns shortUrl, a short 3dcms.info/s/<code> link to the site (one stable code per site), for sharing and QR codes.",
+  "type": "boolean"
+}
    • addedInput schema / properties / siteSlug
      Added value: +{
+  "description": "Publish onto one of YOUR existing sites by its slug (the part after /sites/ in its URL) instead of this scene's own. When that site shows another scene, the first call answers willReplace: name the site to the user and call again with confirmReplace:true on a yes. Later publishes of this scene go to that site.",
+  "type": "string"
+}
  4. Changed1 schema field changed
    • addedInput schema / properties / listed
      Added value: +{
+  "description": "false publishes UNLISTED: reachable by its link, but kept off Explore and your creator profile, marked noindex and not submitted to search engines. Omit for a normal listed publish.",
+  "type": "boolean"
+}
  5. Changed1 schema field changed
    • addedInput schema / properties / confirmReplace
      Added value: +{
+  "description": "Only after a reply with needsConfirm and willReplace: exactly true replaces that live site with this scene. Ask the user first, naming the site.",
+  "type": "boolean"
+}
  6. First observed

TDQS

A4.6/5.0
Behavior5/5

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

Goes well beyond the annotations: destructiveHint=true is explained concretely (URL is submitted to IndexNow the moment it goes live and may persist in search results even after takedown) and it discloses the confirm-gating behavior and stable-URL re-publish semantics. The description also states what the tool returns even though no output schema exists.

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?

Front-loads the usage condition, then the irreversibility warning, then the confirm flow, then return values — a sensible priority order. It is dense and somewhat long, but nearly every sentence carries actionable information, so it earns most of its length.

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?

With no output schema, the description compensates by explaining returns (public site URL plus per-page URL list, and shortUrl when requested). Combined with the confirm/replace workflow and irreversibility warning, an agent has everything needed to call this correctly.

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

Parameters3/5

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

Schema description coverage is 100%, so each parameter is already documented in structured fields, making 3 the baseline. The description reinforces the confirm gate ('without it this tool publishes nothing and returns what WOULD happen') but largely restates parameter behavior already captured 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?

States a specific verb and resource (publish a saved scene) and the outcome (a PUBLIC, shareable 3D URL viewable without login), which clearly separates it from siblings like create_scene, get_scene, and compose_surface. An agent can identify its role without opening the 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?

Explicitly names the triggering conditions ('when the user wants their scene live as a public link to share, or to update one already live') and the required confirm:true gate, so the agent knows both when to call it and the mandatory prerequisite. It even covers the re-publish/update case and the stability of the URL.

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

All 3dCMS toolsInspect
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.

Resources