Skip to main content
Glama

browser_record_start

Destructive

Start recording a video of a browser session to capture all subsequent browser actions. Opens a dedicated tab with profile logins and films until stopped.

Instructions

Start recording a video of a browser session. Opens a dedicated recording tab (with your profile logins); every browser_* action afterwards is filmed until browser_record_stop.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
fpsNo
urlNo
nameNo
widthNo
formatNomp4
heightNo
headlessNo
resourceWaitMsNo
useProfileLoginsNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.1.0

TDQS

A4/5.0
Behavior4/5

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

Annotations declare destructive/openWorld/non-idempotent, and the description adds real behavioral detail beyond them: a dedicated tab is opened, it uses the caller's profile logins, and the recording is scoped to subsequent browser_* actions until stop. It does not explain why the operation is flagged destructive or what happens to the recording output, leaving a small gap.

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?

Two tight sentences, front-loaded with the core action and followed by the lifecycle constraint. No filler or restated title.

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

Completeness3/5

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

For a 9-parameter tool with no output schema, the description covers the lifecycle adequately but says nothing about how the resulting video is identified or retrieved, nor about the parameter space (resolution, format, fps, headless behavior). It is minimally viable rather than complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema has 0% description coverage across 9 parameters (fps, format, width/height, headless, resourceWaitMs, url, name, useProfileLogins), and the description documents none of them. It only obliquely hints at useProfileLogins via 'with your profile logins', so the agent must infer the meaning and units of nearly every parameter.

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 ('Start recording a video of a browser session') and immediately clarifies the mechanism ('Opens a dedicated recording tab'). An agent can distinguish this from browser_record_stop and from browser_screenshot without opening the schema.

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?

Gives clear context — recording begins here and captures 'every browser_* action afterwards ... until browser_record_stop' — which effectively names the terminating sibling. It lacks an explicit when-not-to-use (e.g., versus record_clip or one-off screenshots), so it falls short of a 5.

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

Deploy Server

Other Tools