R3

Show a project in the user's open R3 editor

r3_editor_open

Read-onlyIdempotent

Open a project in the R3 editor the user has open in their browser (their most recently used R3 tab) and focus it, so they see it. A project already open there is just focused (never reloaded). It is how the user gets to see the project you are working on, and how a tab gets the project r3_editor_inspect reads.

The same access rules as opening it by hand: the user's own projects, their teams', and public ones. The editor holds up to 4 projects; at that limit it refuses. Nothing is saved or changed. When no editor is open, the answer says where the user can open one.

Input Schema

Name	Required	Description	Default
`projectId`	Yes	The project to open, from r3_project_list or r3_project_create.

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.
`editor`	Yes
`opened`	Yes
`focused`	Yes
`projectId`	Yes
`alreadyOpen`	Yes
`projectName`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 19, 2026

changedOutput schema / properties / editor / anyOf

Previous value: -[
-  {
-    "additionalProperties": false,
-    "properties": {
-      "lastActiveAgoMs": {
-        "type": "number"
-      },
-      "lastActiveAt": {
-        "type": "string"
-      },
-      "openProjects": {
-        "anyOf": [
-          {
-            "items": {
-              "additionalProperties": false,
-              "properties": {
-                "id": {
-                  "type": "string"
-                },
-                "name": {
-                  "type": [
-                    "string",
-                    "null"
-                  ]
-                }
-              },
-              "required": [
-                "id",
-                "name"
-              ],
-              "type": "object"
-            },
-            "type": "array"
-          },
-          {
-            "type": "null"
-          }
-        ]
-      },
-      "openedAt": {
-        "type": [
-          "string",
-          "null"
-        ]
-      }
-    },
-    "required": [
-      "openedAt",
-      "lastActiveAt",
-      "lastActiveAgoMs",
-      "openProjects"
-    ],
-    "type": "object"
-  },
-  {
-    "type": "null"
-  }
-]New value: +[
+  {
+    "additionalProperties": false,
+    "properties": {
+      "frames": {
+        "anyOf": [
+          {
+            "additionalProperties": false,
+            "properties": {
+              "advancing": {
+                "type": "boolean"
+              },
+              "frameSeen": {
+                "type": "boolean"
+              },
+              "sceneShown": {
+                "type": "boolean"
+              },
+              "visible": {
+                "type": "boolean"
+              }
+            },
+            "required": [
+              "advancing",
+              "visible",
+              "sceneShown",
+              "frameSeen"
+            ],
+            "type": "object"
+          },
+          {
+            "type": "null"
+          }
+        ]
+      },
+      "lastActiveAgoMs": {
+        "type": "number"
+      },
+      "lastActiveAt": {
+        "type": "string"
+      },
+      "openProjects": {
+        "anyOf": [
+          {
+            "items": {
+              "additionalProperties": false,
+              "properties": {
+                "id": {
+                  "type": "string"
+                },
+                "name": {
+                  "type": [
+                    "string",
+                    "null"
+                  ]
+                }
+              },
+              "required": [
+                "id",
+                "name"
+              ],
+              "type": "object"
+            },
+            "type": "array"
+          },
+          {
+            "type": "null"
+          }
+        ]
+      },
+      "openedAt": {
+        "type": [
+          "string",
+          "null"
+        ]
+      }
+    },
+    "required": [
+      "openedAt",
+      "lastActiveAt",
+      "lastActiveAgoMs",
+      "openProjects"
+    ],
+    "type": "object"
+  },
+  {
+    "type": "null"
+  }
+]

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",
-  "projectName",
-  "opened",
-  "alreadyOpen",
-  "focused",
-  "editor"
-]New value: +[
+  "projectId",
+  "projectName",
+  "opened",
+  "alreadyOpen",
+  "focused",
+  "editor",
+  "answer"
+]

First observedOct 15, 2026

TDQS

A4.4/5.0

Behavior5/5

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

Annotations already cover readOnly/idempotent/non-destructive, and the description adds real behavior beyond them: an already-open project is focused and never reloaded, the editor refuses at 4 projects, nothing is saved or changed, and the no-editor case returns guidance on where to open one. These are concrete operational traits an agent cannot infer from the 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?

Front-loaded with the core action and its focus-vs-reload nuance; the second paragraph groups access rules, capacity limit, and no-side-effect guarantees. Slightly dense in places (the r3_editor_inspect aside), but every sentence carries information.

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?

An output schema exists so return values need not be described, and the description still covers the non-obvious cases an agent must handle: nothing persisted, capacity refusal, and the no-open-editor fallback. Complete for a single-parameter tool.

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 coverage is 100% and the projectId property already names its sources (r3_project_list / r3_project_create). The description adds no format, validation, or edge-case semantics for the parameter, so the baseline 3 is appropriate.

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 (open), resource (project), and target surface (the user's currently open R3 editor tab), with the exact behavior of focusing an already-open project. It implicitly distinguishes itself from r3_project_load and r3_editor_create by framing this as 'show the user' rather than load/create.

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?

Explains the reason to call it (it is how the user sees the project, and it is the precondition that r3_editor_inspect reads against) and documents the access rules and the 4-project refusal limit. It does not explicitly exclude or compare against the closest sibling r3_project_load, so it stops short of full when-not guidance.

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?