R3

Change a project's publish settings

r3_publish_settings_set

DestructiveIdempotent

Change publish settings of one of the user's own R3 projects in this environment — the app's Deploy → Settings. Only the settings named change (the rest stay as they are). Only when the user asked for it, or approved the text: these settings shape the PUBLIC live page — its title and description in search results and link previews (seoTitle, seoDescription), Works on (keyboard puts a "made for a keyboard" note on phones and a "desktop" badge; touch a "mobile" badge; both, both; untested none — set it only after the user confirmed it or it was tested, never from the code scan alone), how it starts, its controls. Invalid values are refused with every problem named, and nothing is saved. The answer names what changed; open live and preview pages are told (a preview reloads, a live page offers a reload). Takes effect without a new release. Needs the publish:live right. R3 admins only: gallery features, hides or sets the example prompt of a project in the landing gallery (any member's project; send it without settings for a project that is not yours).

Input Schema

Name	Required	Description
`gallery`	No	R3 admins only: the landing gallery, e.g. {"featured": true} or {"examplePrompt": "…"}.
`settings`	No	Only the settings to change, e.g. {"worksOn": "keyboard", "seoDescription": "…"}.
`projectId`	Yes	The project id (r3_project_list).

Output Schema

Name	Required	Description
`answer`	Yes	This answer in words: what was done, what R3 measured, decided or refused, and what to do next. The same text as the result's text block. Read it: the fields beside it are the data, this is the guidance.
`changed`	Yes
`gallery`	No
`projectId`	Yes
`environment`	Yes
`portalSettings`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedOct 29, 2026

addedInput schema / properties / gallery

Added value: +{
+  "additionalProperties": false,
+  "description": "R3 admins only: the landing gallery, e.g. {\"featured\": true} or {\"examplePrompt\": \"…\"}.",
+  "properties": {
+    "examplePrompt": {
+      "description": "The exact prompt that made this project, shown with a \"Made by R3\" label and a Copy prompt button (up to 500 characters; empty clears it). Only on a project an R3 account owns.",
+      "maxLength": 500,
+      "type": "string"
+    },
+    "featured": {
+      "description": "true pins the project to the top of the landing gallery; false unpins it.",
+      "type": "boolean"
+    },
+    "hidden": {
+      "description": "true keeps the project out of the landing gallery (its live page stays); false shows it again.",
+      "type": "boolean"
+    }
+  },
+  "type": "object"
+}

changedInput schema / required

Previous value: -[
-  "projectId",
-  "settings"
-]New value: +[
+  "projectId"
+]

addedOutput schema / properties / gallery

Added value: +{
+  "additionalProperties": false,
+  "properties": {
+    "examplePrompt": {
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "featured": {
+      "type": "boolean"
+    },
+    "hidden": {
+      "type": "boolean"
+    }
+  },
+  "required": [
+    "featured",
+    "hidden",
+    "examplePrompt"
+  ],
+  "type": "object"
+}

Changed2 schema fields changedOct 27, 2026

changedInput schema / properties / settings / properties / autoStart / description

Previous value: -"How the live page starts: startButton (a Start button), firstGesture (the first click anywhere), load (on load: physics and code only, no audio)."New value: +"How the live page starts: auto (the default: a Start button only when the project has sound or physics, else it starts on load), startButton (always a Start button), firstGesture (the first click anywhere), load (on load: physics and code only, no audio)."

changedInput schema / properties / settings / properties / autoStart / enum

Previous value: -[
-  "load",
-  "startButton",
-  "firstGesture"
-]New value: +[
+  "auto",
+  "load",
+  "startButton",
+  "firstGesture"
+]

Changed1 schema field changedOct 25, 2026

removedInput schema / properties / settings / properties / publishMode

Removed value: -{
-  "description": "What the editor's Save does for a live project: ask, auto (publish) or manual.",
-  "enum": [
-    "ask",
-    "auto",
-    "manual"
-  ],
-  "type": "string"
-}

Changed2 schema fields changedOct 15, 2026

addedOutput schema / properties / answer

Added value: +{
+  "description": "This answer in words: what was done, what R3 measured, decided or refused, and what to do next. The same text as the result's text block. Read it: the fields beside it are the data, this is the guidance.",
+  "type": "string"
+}

changedOutput schema / required

Previous value: -[
-  "projectId",
-  "environment",
-  "changed",
-  "portalSettings"
-]New value: +[
+  "projectId",
+  "environment",
+  "changed",
+  "portalSettings",
+  "answer"
+]

First observedOct 15, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Adds substantial context beyond the annotations: atomic validation ('refused with every problem named, and nothing is saved'), call effects ('open live and preview pages are told...'), 'takes effect without a new release', required 'publish:live' right, and admin-only gallery scope. These are exactly the behavioral traits an agent needs before mutating public-facing state.

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 purpose and is dense with no filler, but it is a single running paragraph heavy on nested parentheticals that would read better as structured clauses. Slightly overpacked, though every element is substantive.

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 complex mutation tool it covers permissions, atomicity, propagation to live/preview, admin-only branch, and the partial-update rule, while the output schema and rich schema descriptions handle return values and field detail. Nothing essential to a correct call 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?

With 100% schema coverage the baseline is 3, but the description adds meaning the schema doesn't spell out — the partial-update contract and the consequence of worksOn on the public page (badges/notes). It still leaves nested controls/startButton behavior to 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+resource ('Change publish settings of one of the user's own R3 projects') and pins down the surface it maps to ('Deploy → Settings'). It also clarifies the partial-update semantics ('Only the settings named change'), making it clearly distinct from the read sibling.

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?

Gives explicit when-to-use conditions ('Only when the user asked for it, or approved the text') and a strong when-not ('never from the code scan alone') for the risky worksOn field. It does not name the read sibling r3_publish_settings_read as the alternative, but the conditions otherwise leave little to inference.

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

All R3 tools Inspect

Try in Browser

Shareable, User-Owned Context BackendPeople, applications, and agents read, write, and coordinate together in one context lake. Reach it over MCP, a CLI, a Python SDK, or REST.fulcradynamics.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?