Screen Browser

Save guide

put_guide

Save a guide on a project. With guide_id it is a new version of that guide; with a name no main guide on the project has yet it starts a new guide (one project can hold many videos); otherwise it is a new version of the newest guide. kind "auth" is the login flow (never recorded, may use {USERNAME}/{PASSWORD}); kind "main" is the walkthrough that becomes the video. Call get_guide_instructions before writing a guide and validate_guide before saving it.

Input Schema

Name	Required	Description
`kind`	Yes	auth = the login steps, run before recording and never shown; main = the walkthrough that becomes the video.
`name`	No	Display name for a main guide, e.g. "Create your first campaign". A name the project has not used yet starts a new guide.
`content`	Yes	The guide text, one step per line (get_guide_instructions has the syntax); up to 20000 characters.
`guide_id`	No	Save as a new version of this guide (from list_projects or put_guide).
`project_id`	Yes	The project (from create_project or list_projects).
`video_title`	No	Title shown on the video's opening (main guides). Empty uses the guide name.

Output Schema

Name	Required	Description
`kind`	Yes
`name`	Yes
`lines`	Yes	Non-empty lines saved.
`version`	Yes	Versions count up per guide; earlier versions are kept.
`guide_id`	Yes	Pass as guide_id to start_run to record exactly this version.
`project_id`	Yes
`video_title`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedOct 31, 2026

changedInput schema / properties / content / description

Previous value: -"The guide text, one step per line (see screenbrowser://guide-syntax); up to 20000 characters."New value: +"The guide text, one step per line (get_guide_instructions has the syntax); up to 20000 characters."

addedInput schema / properties / guide_id

Added value: +{
+  "description": "Save as a new version of this guide (from list_projects or put_guide).",
+  "type": "string"
+}

changedInput schema / properties / name / description

Previous value: -"Display name for a main guide, e.g. \"Create your first campaign\"."New value: +"Display name for a main guide, e.g. \"Create your first campaign\". A name the project has not used yet starts a new guide."

First observedSep 26, 2026

TDQS

A4.6/5.0

Behavior4/5

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

Goes well beyond the annotations by disclosing that auth guides are never recorded and may use {USERNAME}/{PASSWORD} placeholders, that main guides become the video, and that saves create new versions rather than overwriting (relevant to the idempotentHint=false). It doesn't discuss permissions or failure behavior, but the added context is substantial.

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?

Dense but front-loaded: the core save action and versioning rules come first, prerequisites last. The conditional versioning clause is somewhat convoluted 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?

With an output schema present, return values needn't be explained, and the description covers the meaningful gaps: versioning semantics, auth vs main behavior, prerequisites, and placeholders. An agent can call this correctly from the description alone.

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 interpretation, notably that an unused name starts a new guide while a used one rolls into the newest guide, and that guide_id implies versioning. It repeats rather than extends the kind semantics already documented in the enum description.

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 ("Save a guide on a project") and immediately disambiguates the three save modes (new version by guide_id, new guide by unused name, new version of newest otherwise). This clearly separates it from siblings like get_guide and validate_guide.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

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

Explicitly names prerequisites and ordering: "Call get_guide_instructions before writing a guide and validate_guide before saving it." It also spells out the selection rule among the three save paths, leaving nothing to inference.

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.