Screen Browser

Get run

get_run

Read-onlyIdempotent

Status of a run: phase, whether it is finished, credits so far, the customer-visible activity, the error with a hint when it failed, and signed URLs for the video and other artifacts (GET only, valid ~15 minutes; call again for fresh ones).

Input Schema

TableJSON Schema

Name	Required	Description	Default
`run_id`	Yes	The run to describe (from start_run or list_runs).

Output Schema

TableJSON Schema

Name	Required	Description
`mode`	Yes	record produces a video; check only verifies the guide.
`error`	No	Present only when the run failed.
`guide`	No	Display name of the guide that was recorded.
`phase`	Yes	Customer-facing phase label (Queued, Preparing, Recording, Finishing, Completed, Failed, Paused).
`state`	Yes	Machine-readable state; done means the video is ready.
`output`	No	Device settings the run recorded with (device, frame, backdrop).
`run_id`	Yes
`attempt`	Yes	Attempt number; the recorder retries some failures itself.
`activity`	Yes	Customer-visible activity lines, oldest first, each prefixed with its time.
`warnings`	Yes	Things that stayed on top of the page during the walkthrough; fix the guide and run again.
`artifacts`	Yes
`video_url`	No	Signed download link for the video, valid about 15 minutes; null until the video is ready.
`phase_note`	Yes	One line explaining the phase.
`project_id`	Yes
`started_at`	No	ISO 8601
`is_terminal`	Yes	true when nothing more will happen; stop polling.
`completed_at`	No	ISO 8601
`output_label`	Yes	Human label of the output, e.g. Desktop or iPhone, Vertical 9:16.
`video_seconds`	No	Length of the finished video.
`credits_so_far`	Yes	Credits owed so far; 0 until the video completes.
`estimated_credits`	No	Estimate made when the run started.

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedSep 26, 2026

addedOutput schema / properties / warnings

Added value: +{
+  "description": "Things that stayed on top of the page during the walkthrough; fix the guide and run again.",
+  "items": {
+    "properties": {
+      "code": {
+        "description": "page_furniture",
+        "type": "string"
+      },
+      "kind": {
+        "enum": [
+          "cookie_banner",
+          "chat_widget",
+          "dialog"
+        ],
+        "type": "string"
+      },
+      "message": {
+        "type": "string"
+      },
+      "suggestion": {
+        "description": "The guide line to add, e.g. If visible, click \"Accept all\".",
+        "type": [
+          "string",
+          "null"
+        ]
+      },
+      "when": {
+        "description": "Seen from the first frame, or still there at the end.",
+        "enum": [
+          "start",
+          "end"
+        ],
+        "type": "string"
+      }
+    },
+    "required": [
+      "code",
+      "kind",
+      "when",
+      "message"
+    ],
+    "type": "object"
+  },
+  "type": "array"
+}

changedOutput schema / required

Previous value: -[
-  "run_id",
-  "project_id",
-  "state",
-  "mode",
-  "phase",
-  "phase_note",
-  "is_terminal",
-  "attempt",
-  "credits_so_far",
-  "output_label",
-  "activity",
-  "artifacts"
-]New value: +[
+  "run_id",
+  "project_id",
+  "state",
+  "mode",
+  "phase",
+  "phase_note",
+  "is_terminal",
+  "attempt",
+  "credits_so_far",
+  "output_label",
+  "activity",
+  "warnings",
+  "artifacts"
+]

First observedSep 26, 2026

TDQS

A4.5/5.0

Behavior5/5

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

Beyond annotations (readOnlyHint, idempotentHint), the description discloses that this is GET-only, that signed artifact URLs expire after ~15 minutes, and that fresh URLs require a subsequent call. This adds meaningful runtime behavior not captured by the schema or annotations.

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

Conciseness5/5

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

A single, dense sentence organizes status components as a list and tucks the expiration behavior into a parenthetical. Every word adds information and the key action is front-loaded. No redundancy or fluff.

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 one-parameter read tool with an output schema, the description covers all essential runtime concerns: what data is returned, the read-only nature, and the temporary URL behavior. An agent can safely and correctly invoke it without additional documentation.

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% and the description contributes no additional run_id semantics beyond what the schema already states ('from start_run or list_runs'). Baseline 3 is appropriate because the schema fully carries parameter meaning.

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?

The description begins 'Status of a run' which precisely states the resource (run) and the action (retrieve status). It enumerates specific status fields (phase, finish flag, credits, activity, error, signed URLs), making it immediately distinct from sibling tools like list_runs (all runs) or cancel_run (mutation).

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 implies clear usage: when you have a run_id and need its current status, call this tool. It adds that repeated calls are expected ('call again for fresh ones') but does not explicitly compare against siblings or state exclusions. Context is clear enough, but no alternatives are named.

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

All Screen Browser tools Inspect

Try in Browser

Let your AI agent see the webWeb-to-screenshot MCP for Claude, Cursor and Codex. No cookie banners. Free to start.snap-render.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.