Screen Browser

Start run

start_run

Start recording a video for a project (its newest main guide, or a specific guide_id), on the desktop or as a phone/tablet (device). Returns the run id; poll get_run until is_terminal. Credits are charged only when the video completes.

Input Schema

Name	Required	Description
`frame`	No	Phones: portrait (9:16 in a phone frame, default), landscape (16:9 widescreen with the phone upright and centred, for YouTube) or none (the bare screen). Tablets: landscape or none.
`voice`	No	Narrate this video with a specific voice id from list_voices; default is the project's voice.
`device`	No	Record as a phone or tablet instead of the desktop: desktop, iphone, iphone-max, android, android-large, ipad, ipad-pro, android-tablet. One run is one device; for a desktop and a phone version start two runs with the same guide. Default is the project's device.
`backdrop`	No	Behind the phone frame: neutral (grey, default) or brand (the organisation's brand kit colour).
`guide_id`	No	A specific main guide id (from put_guide or list_projects); default is the newest.
`language`	No	Narrate in this language (code from list_voices); default is the project's language.
`project_id`	Yes	The project to record (from create_project or list_projects).

Output Schema

Name	Required	Description
`next`	Yes	What to do now.
`state`	Yes
`output`	No	Device, frame and backdrop the video will use.
`run_id`	Yes	Poll get_run with this id.
`narration`	No	Language and voice the video will use.
`credits_per_minute`	Yes	What this video costs per minute of finished video (openings and endings are free). Charged only when the video completes.

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedOct 23, 2026

addedOutput schema / properties / credits_per_minute

Added value: +{
+  "description": "What this video costs per minute of finished video (openings and endings are free). Charged only when the video completes.",
+  "type": "number"
+}

removedOutput schema / properties / estimated_credits

Removed value: -{
-  "description": "Expected cost; charged only when the video completes.",
-  "type": [
-    "number",
-    "null"
-  ]
-}

changedOutput schema / required

Previous value: -[
-  "run_id",
-  "state",
-  "next"
-]New value: +[
+  "run_id",
+  "state",
+  "credits_per_minute",
+  "next"
+]

First observedSep 26, 2026

TDQS

A4.7/5.0

Behavior5/5

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

Beyond the annotations (readOnlyHint=false, openWorldHint=true, idempotentHint=false, destructiveHint=false), the description discloses the async lifecycle (poll get_run until is_terminal), the return value (run id), and the cost model (credits charged only when the video completes). The billing timing is exactly the kind of non-obvious consequence annotations cannot express.

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?

Three dense sentences covering what, how, and the cost/return consequences, with the core action front-loaded and zero filler. Every clause carries actionable 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?

For a non-idempotent, open-world mutation that starts an async job, the description covers the trigger, the polling requirement, the identifier returned, and when money is spent. With an output schema present, no further return-value explanation is required.

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?

Schema coverage is 100%, so the baseline is 3; the description still adds value by explaining the guide_id default ("newest main guide") and that device selects desktop versus phone/tablet rendering. It does not touch frame, voice, language, or backdrop, but those are already well documented 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 ("Start recording a video for a project") plus the two scoping choices that matter: which guide (newest vs. a specific guide_id) and which surface (desktop vs. phone/tablet device). An agent can distinguish this from create_project, put_guide, or get_run 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 Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives the operational sequence explicitly: call this, then poll get_run until is_terminal. It is clear when to invoke it, though it does not name a when-not condition or contrast with a sibling (e.g., validate_guide as a pre-step) — that context is inferable but not stated.

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

Claude Code, inside the Godot 4 editorFlockbay puts an AI agent in the real Godot 4 editor: it writes GDScript, runs your game and fixes what breaks. Free, or bring your own Claude Code or Codex.flockbay.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.