R3

Read a project's publish settings

r3_publish_settings_read

Read-onlyIdempotent

Read the publish settings of one of the user's own R3 projects in this environment — what the app's Deploy → Settings shows: Works on (keyboard / touch / both / not tested), the SEO title and description that search engines and link previews show, how the live page starts (Start button, first click, on load), its controls and badge. Also answers a SUGGESTION for Works on, from a scan of the project's code for keyboard / touch / pointer handlers — only a suggestion. r3_publish_settings_set changes them. Needs the project:read right.

Input Schema

Name	Required	Description	Default
`projectId`	Yes	The project id (r3_project_list).

Output Schema

Name	Required	Description
`live`	Yes
`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.
`gallery`	No
`worksOn`	Yes
`seoTitle`	Yes
`projectId`	Yes
`environment`	Yes
`portalSettings`	Yes
`seoDescription`	Yes
`worksOnSuggestion`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 29, 2026

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 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",
-  "worksOn",
-  "seoTitle",
-  "seoDescription",
-  "portalSettings",
-  "worksOnSuggestion",
-  "live"
-]New value: +[
+  "projectId",
+  "environment",
+  "worksOn",
+  "seoTitle",
+  "seoDescription",
+  "portalSettings",
+  "worksOnSuggestion",
+  "live",
+  "answer"
+]

First observedOct 15, 2026

TDQS

A4.2/5.0

Behavior4/5

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

Annotations already declare readOnly, idempotent, non-destructive, and openWorld, so the safety profile is covered; the description adds genuinely non-obvious context — the permission requirement, ownership scoping, and the caveat that the 'Works on' value is only a code-scan SUGGESTION. It does not discuss response shape, but an output schema exists so that burden is elsewhere.

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?

Information is front-loaded with the verb and the core payload first, then the caveat and the alternative tool. The single dense sentence with em-dash and parentheticals is slight over-packing, but every clause carries useful content.

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 annotations covering safety, an output schema covering returns, and a fully documented single parameter, the description still adds permissions, ownership scope, the suggestion caveat, and the write counterpart. An agent has everything needed to decide and invoke 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?

There is a single parameter with 100% schema coverage, and the schema documents projectId as coming from r3_project_list. The description only restates that the project must be one of the user's own, adding ownership constraint but no format or lookup detail beyond the schema, so the baseline 3 applies.

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 ('Read the publish settings') and then enumerates the concrete fields returned (Works on, SEO title/description, start behavior, controls, badge), so an agent knows exactly what this yields. It also names the mutation sibling r3_publish_settings_set, making the read/write split unambiguous.

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 scopes usage to 'one of the user's own R3 projects in this environment' and states the required 'project:read' right, plus points at r3_publish_settings_set for changes. There is no explicit exclusion (e.g., what happens for unpublished or other users' projects), so it stops short of a full when/when-not statement.

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?