Skip to main content
Glama

start_recording

Start a background recording of any URL in headless Chromium, enabling you to work while it captures. Use markers and chapters to narrate, then stop to upload.

Instructions

Start a RECORDING SESSION: opens the given URL in a headless Chromium that keeps recording in the background while you continue working. Use add_marker to narrate (and optionally ASSERT on-screen state) at each step, add_chapter for before/after boundaries, then stop_recording to upload and get the share link. Set type for the recording kind, storageState/initScript to record behind a login, and exposeCdp to get a CDP endpoint you can drive with your own Playwright while it records. The session auto-stops and uploads by itself at maxSeconds (default 600) so a forgotten session can never run away. One session at a time. Requires Playwright + an ingest-scoped CLIPY_API_KEY (like the record tool). Recording the REAL Mac screen or a window's initial screen area (ScreenCaptureKit, real logged-in browser) is CLI-only — clipy session start --source mac-screen --window "<app>" — and not available via MCP. Quick per-cookie / per-localStorage-key injection (the CLI's --cookie / --local-storage) is CLI-only — use storageState here; and backdating a mark by a relative offset (the CLI's --ago) is CLI-only — use add_marker's atSeconds. The result reports the RESOLVED capture source (source: the post-redirect URL, page title and viewport actually being recorded) — compare it against the surface your driver is acting on BEFORE doing minutes of work, because Clipy will never focus or foreground a window or tab for you. This call waits for the initial navigation to settle before replying (bounded by the same 30s page-load timeout) so that reported source is measured rather than guessed — recording and the auto-stop rail both start immediately, so only the reply waits.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
urlYesThe http(s) URL to open and record (e.g. http://localhost:3000).
nameNoOptional title for the recording.
typeNoWhat the recording IS, so the AI summary doesn't misread it. One of: bug_report, feature_request, product_demo, walkthrough_tutorial, feedback_review, discussion_talk, other (aliases like bug/feature/demo/tutorial/review/talk accepted).
widthNoViewport + video width (default 1280).
heightNoViewport + video height (default 720).
exposeCdpNoOpen a Chrome DevTools Protocol endpoint on the recording browser (default false) so you can drive the page (navigate/click/type) with your own Playwright WHILE it records. When on, the result returns cdpHttpUrl + cdpUrl and driver notes, AND the recorded page exposes window.__clipyMark(text, {assertSelector, assertText, assertUrl, failMode}) + window.__clipyChapter(label) so a CDP driver can drop asserted marks/chapters with zero extra tool calls. OFF by default (while open, any local process can attach). The env var CLIPY_DISABLE_CDP=1 is a hard kill switch that forces it off.
initScriptNoPath to a JS file run in the page before every navigation (context.addInitScript). Contents are never logged.
maxSecondsNoAuto-stop ceiling in seconds (default 600, hard cap 1800). On expiry the session uploads what it captured.
descriptionNoOptional description for the recording.
userDataDirNoPath to a Chromium user-data ROOT — the dir holding 'Local State' plus profile subdirs (macOS Chrome: ~/Library/Application Support/Google/Chrome). WITHOUT profileDirectory, Clipy opens this dir's 'Default' profile directly and writes to it, so it is refused while a live Chrome holds it locked (quit Chrome first). WITH profileDirectory, Clipy COPIES that named profile into a temporary root and records the copy — your real profile is never opened or modified. A profile SUBDIR passed as the root is refused. Mutually exclusive with storageState.
storageStateNoPath to a Playwright storageState JSON (cookies + localStorage) to record behind a login. Passed unchanged to the browser context; its contents are never logged. Mutually exclusive with userDataDir.
profileDirectoryNoWhich profile INSIDE userDataDir to record — 'Default', 'Profile 1', 'Profile 2', … (exact folder name from chrome://version → 'Profile Path'). Clipy COPIES that profile into a temporary scratch root (as its Default) and records the copy: your real profile is never opened or modified, and the copy is deleted after upload. The result discloses the copy. Requires userDataDir. (Playwright strips Chromium's --profile-directory, so copying is the only way to select a named profile.)
Install Server

TDQS

A4.6/5.0
Behavior5/5

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

With no annotations provided, the description carries the full burden and does so superbly. It discloses that recording happens in the background, that the session auto-stops at maxSeconds, that it waits for navigation before replying, that it reports the resolved source rather than guessing, and that Clipy will never focus or foreground a window. Security details (CDP off by default, CLIPY_DISABLE_CDP kill switch) are also included.

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 long (over 300 words) but dense and well-sorted: it front-loads the core purpose, then details parameters, then limitations, then return behavior. Every paragraph earns its place, though a more concise opening could help agents that need to skim quickly.

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 tool with 12 params and no output schema, this description covers all the bases: what it does, how it fits the workflow, what the result reports (source, title, viewport), auto-stop behavior, waiting semantics, and constraints (one session, CLI-only alternatives). An agent has enough to call it correctly without guessing.

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 adds genuine value by explaining param nuances: the mutual exclusivity of storageState and userDataDir, the copy-vs-destroy behavior of profileDirectory, the security implication of exposeCdp being off by default, and the auto-stop ceiling semantics. This goes well beyond the schema's one-line descriptions.

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 precise verb+resource ('Start a RECORDING SESSION: opens the given URL in a headless Chromium that keeps recording in the background') and immediately orients the tool within its workflow (add_marker, add_chapter, stop_recording). It clearly distinguishes itself from siblings by describing its role as the session launcher, and even notes CLI-only alternatives for features it doesn't support.

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?

Provides clear context on when to use this tool (as part of a recording workflow, one session at a time) and explicitly excludes CLI-only options (mac-screen, cookie/local-storage, --ago) by guiding the user to storageState and add_marker. However, it does not explicitly contrast with the sibling 'record' tool, leaving some ambiguity about which to choose when both are present.

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

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/manovagyanik1/clipy-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server