Skip to main content
Glama

Clueso

by io.clueso

Record screen

record_screen

Create a screen-recording clip in a project. Creates blank placeholder clips, registers job entities, and sends the job to AVS.

The blank clips this tool creates are placeholders; they become video clips when processing completes, so removing one loses that scene. Article placeholders are also inserted automatically into plainDoc.

Requires the Auto-Recording add-on and per-workspace sign-in credentials for the product being recorded. Workspaces without it get back the manual path instead (upload_file, then add_clips(kind='video')) rather than a failure.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
scenesYesREQUIRED — the recording to make, as a list of scenes. This is the ONLY way to specify what to record. A normal single recording is exactly ONE scene; a code-wizard multi-scene / marketing video is N scenes (one clip per scene, and ALL cuts of one video go in a SINGLE record_screen call). A narrated scene REQUIRES a non-empty narration_script; a b-roll scene is silent (no narration, no article). A cut that starts somewhere disconnected is just a scene with entry.mode "fresh". Cleopatra orgs accept exactly ONE narrated scene. Do not set scene_id — it is assigned server-side.
chat_idYesConversation context ID
guide_idYesTarget guide ID
languageNoLanguage code for the recording (default: en)en
edit_scene_idsNoThe clip id(s) this edit replaces. Only used when recording_session_id is set; scenes you do not name are not re-filmed. Set preceding_clip_id to the clip you are replacing — an edit naming a clip that is not in the guide is refused rather than appended to the end.
video_intentionNoOne-line intent shared across all scenes of a multi-scene recording (e.g. "punchy 30s launch teaser for feature X"). Ignored for single-scene recordings.
preceding_clip_idYesClip ID after which to insert the new clip
exact_video_scriptNoSet to true when the video narration must be used exactly as written — the agent that does the recording will not reword, rephrase, or rewrite video_script at all. Default false.
custom_instructionsNoOptional per-recording instructions (e.g. "select project X", "add rectangle 200x100"). Not related to mocking.
exact_article_scriptNoSet to true when the article must be used exactly as written — the agent that does the recording will not reword, rephrase, or rewrite article_script at all. Default false.
recording_session_idNoEDIT an existing recording instead of shooting a new one. Pass the recording_session_id from the record_screen that made it, or read it off get_clip. The recorder restores that take's code, notes and click script and changes only what you ask for, which is far faster and cheaper than re-recording. Omit for a fresh recording. Only code-wizard recordings are editable; get_clip omits the field for any clip that is not.

TDQS

A4.6/5.0
Behavior5/5

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

The description adds significant behavioral detail beyond the annotations: clips are placeholders that become video only after processing, deleting one loses that scene, article placeholders are inserted into plainDoc, and jobs are sent to AVS. There is no contradiction with the readOnlyHint=false or destructiveHint=false 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?

The description is compact and front-loaded: the core action appears first, followed by placeholder semantics, prerequisites, and fallback behavior. Each sentence provides distinct information without filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a complex asynchronous tool with no output schema, the description covers the core action, side effects, prerequisites, and alternative path well. The main gap is that it never states the return value or response shape, though the recording_session_id parameter and AVS references indirectly signal async behavior.

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?

The schema already provides 100% parameter coverage with rich explanations, so the description is not required to repeat parameter details. It does not add parameter-specific meaning, but no extra compensation is needed given the high schema coverage.

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 states a precise action: 'Create a screen-recording clip in a project,' and further clarifies the pipeline by mentioning blank placeholder clips, job entities, and AVS submission. It also distinguishes itself from the manual path (upload_file, then add_clips) so an agent can tell it apart from sibling tools.

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?

The description gives explicit when-to-use guidance: it requires the Auto-Recording add-on and per-workspace credentials, and clearly names the fallback for workspaces without it: 'upload_file, then add_clips(kind='video')'. This is a concrete decision rule rather than an implied usage.

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

All Clueso toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.1/5.0
Disambiguation4/5

Most tools have clearly distinct purposes, but there is notable overlap between remove_elements and remove_from_project(target='element'), which both remove elements from a clip. This duplication could cause an agent to misselect. Otherwise, tools like add_clips, add_elements, add_audio, and analyze_audio are well-differentiated.

Naming Consistency5/5

All tools follow a consistent verb_noun pattern (e.g., add_clips, create_project, get_clip, update_elements). There are no camelCase or mixed conventions. Even compound names like voiceover_batch and auto_sync fit the pattern. This makes the tool set predictable for an agent.

Tool Count2/5

With 40 tools, the set is significantly larger than the 3-15 range that typically earns its place. While the domain of video creation is broad, several tools seem redundant (remove_elements vs remove_from_project) or narrowly scoped (get_design_guide, get_element_schema), inflating the count. The number feels heavy for the apparent scope.

Completeness4/5

The tool surface covers most lifecycle operations: create, read, update, delete for projects, clips, elements, audio, articles, and clueprints. Minor gaps exist, such as no explicit tool to delete a voiceover (only mute via update_clips) and no folder management beyond listing. Overall, agents can accomplish full workflows with few workarounds.

Resources