Skip to main content
Glama

Track and replace a screen recording's cursor

track_cursor

Find the mouse cursor of a screen recording on every frame, with its clicks and scrolls, and make the recording a Vidova screen recording: a new video asset of the same recording, its own cursor taken out (removeCursor null or true), that plays as a recording clip. Vidova then draws its own cursor there, the size and style you set (cursorStyle, cursorSize), smooth, with click sounds and click effects, and every on the clip follows the cursor. Use it on any uploaded screen recording before you zoom on, follow, highlight or replace the cursor: a tutorial, a SaaS walkthrough, a demo, a screen share from a call. Do not follow a cursor with track_box. The answer gives the new Asset ID, how sure each click is and where it is, the scrolls with their times, and an object track of the cursor (, , ). The new asset has the source's sound and length: put it where the source was, and wait_for_asset it first. Read builtin-screen-recordings before you place it. Uses about 38 credits a minute of the recording, billed by the second.

Input Schema

NameRequiredDescriptionDefault
assetIdYesThe screen recording's video asset: an uploaded tutorial, walkthrough, demo or call screen share. Use the IDs search_assets gives.
projectIdYesThe project this call runs on without changing the open project. null (or leaving it out) uses the open project. wait_for_jobs takes the projectId of the calls that started the jobs.
removeCursorYestrue or null: the new asset is the recording with its own cursor taken out, so Vidova's cursor is the only one on screen. false: the new asset keeps the recording's cursor as it was filmed, with its path and clicks for zooms that follow it and click effects.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.6/5.0
Behavior5/5

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

Beyond annotations, the description discloses that it creates a new asset rather than mutating the source, that cursorStyle/cursorSize control Vidova's replacement cursor, that click sounds and effects are added, that zooms follow the cursor, and that it costs about 38 credits per minute billed by the second. It also warns to wait_for_asset and read builtin-screen-recordings before placement.

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?

The description is front-loaded with the core action and then packs in prerequisites, cost, output, and placement guidance. It is dense but mostly earns its length; a few sentences are run-on and the parenthetical notation makes it less scannable than it could be.

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 complex, non-idempotent asset-producing tool with no output schema, the description is very complete: it explains what is returned (new Asset ID, click confidence/location, scroll times, object track), how to place the new asset, and operational prerequisites. An agent has enough to call it correctly.

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%, so the schema already documents assetId, projectId, and removeCursor in detail; the description mostly repeats removeCursor's null/true versus false behavior rather than adding new parameter syntax. It also mentions cursorStyle and cursorSize, which are not present in the input schema, creating some potential confusion.

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 specific verb and resource: find the mouse cursor on every frame and produce a new Vidova screen recording with its own cursor removed or retained. It clearly distinguishes this from cursor-following tools by saying not to use track_box for this purpose.

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?

It explicitly says when to use it before zooming, following, highlighting, or replacing the cursor, lists tutorial/walkthrough/demo/call examples, and names track_box as the wrong alternative. This is close to ideal routing guidance.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.