Skip to main content
Glama

Demo video of a website

record_demo_video

Records a short website demo video from a page tour or step file, hides cookie banners and chat bubbles, and saves MP4, GIF, poster, and step timing data.

Instructions

Records a short demo video of a website: a tour of the pages worth showing, or the steps in a file. The page plays in a browser window on a backdrop, with a visible pointer, smooth scrolling and a zoom on each click. Cookie banners and chat bubbles are hidden, never clicked. Saves demo.mp4 (1920x1080, H.264), demo.gif, poster.png and steps.json, which says where every step starts and ends, in seconds and in frames. (easyscreenshotkit 0.1.1, on this machine.)

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "url": "<url>"
    },
    "name": "record_demo_video"
  }
}

Input Schema

NameRequiredDescriptionDefault
fpsNoFrames a second (default 30).
gifNoSet to false to skip demo.gif.
urlYesThe website, like https://linear.app
hideNoCSS selectors of more elements to hide.
langNoThe site's version in this language, when it has one.
pageNoPages to take in the tour, like /pricing.
zoomNoHow far a click zooms in, 1 to 2.5 (default 1.5). 1 means no zoom.
cleanNoSet to false to keep the banners and bubbles.
frameNoSet to false for the page alone, filling the video.
pagesNoPages in the tour, the home page included (default 4).
stepsNoA YAML or JSON file of steps to follow instead of a tour: visit, scroll, click, type, wait, hover, key.
themeNoThe site's light or dark look (default light).
out_dirNoFolder to save into, absolute or relative to /app. Default: easyscreenshotkit-demo-{host}.
backgroundNoBehind the window: a colour like #0f172a, two or three colours for a gradient, or a picture file.
wait_secondsNoHow long to wait for the result before returning a job_id to wait on. 45 is safe for clients that stop a tool call after 60 seconds.
reduced_motionNoAsk the site for its reduced-motion version.
timeout_secondsNoGive up after this many seconds (default 900).

Output Schema

NameRequiredDescriptionDefault
kitYes
toolYes
filesNo
folderNoWhere the kit saved its files.
job_idYes
passedNoFor checks: whether the check passed.
statusYes
exit_codeNo
last_lineNoWhat the kit was doing last.
expires_atNoWhen the download links stop working.
next_actionNo
elapsed_secondsYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.1/5.0
Behavior4/5

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

Well beyond the annotations, it discloses the rendering behavior (browser window on a backdrop, visible pointer, smooth scrolling, click zoom) and that cookie banners and chat bubbles are hidden rather than clicked. It also explains the asynchronous escape hatch: after wait_seconds it returns a job_id to wait on, which the annotations don't convey. Still silent on whether it needs live network access to the target site or what happens on failures.

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?

Front-loaded with purpose and mode, then behavior, then output files, then the timing caveat — a sensible order with little filler. The parenthetical version string and the dense artifact list in one sentence cost it a point but nothing is truly wasted.

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 17-parameter job-launching tool with an output schema and annotations, the description covers outputs, the async job_id path, and the visual conventions an agent needs to set expectations. It stops short of stating prerequisites such as internet access to the target URL or how failures surface.

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 schema already documents each parameter and a 3 would be the baseline. The description earns extra credit by explaining the behavior behind key flags: banners/bubbles are hidden (clean), the page fills the video (frame), a gif is produced (gif), and zoom corresponds to a click rather than a static scale.

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?

"Records a short demo video of a website" gives a specific verb plus resource, and the description immediately specifies the two modes (a page tour, or a steps file). The named artifacts (demo.mp4, demo.gif, poster.png, steps.json) make it unmistakable against siblings like take_screenshots or make_launch_film.

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

Usage Guidelines3/5

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

Usage is implied rather than stated: the tour-vs-steps split tells the agent two ways to drive it, and wait_seconds explains the 45s guidance for clients that cut off at 60s. But it never says when to choose this over take_screenshots or make_launch_film, and offers no explicit exclusions.

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