browser_start_video
Record a browser video by specifying the width, height, and filename to save the output.
Instructions
Start video recording
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| size | No | Video size | |
| filename | No | Filename to save the video. |
Record a browser video by specifying the width, height, and filename to save the output.
Start video recording
| Name | Required | Description | Default |
|---|---|---|---|
| size | No | Video size | |
| filename | No | Filename to save the video. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=true and destructiveHint=false, but 'starting video recording' implies a potentially mutating state (recording resources started). The description does not disclose behavioral traits beyond annotations, such as whether recording affects browser performance, requires user permissions, or produces a file immediately. With annotations present, the low burden makes a 3 reasonable, though contradictions are absent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no wasted words. It front-loads the key action ('start video recording'), though it could benefit from additional brief context (e.g., what kind of video). The structure is efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (2 parameters, nested object), lack of output schema, and context signals with no enums, the description is incomplete. It does not explain how the recorded video is used, if it starts immediately, or what the filename extension should be. Sibling tools like browser_stop_video exist but are not referenced.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents 'size' and 'filename' with descriptions. The description 'Start video recording' adds no additional semantic meaning beyond what the schema provides, leading to a baseline score of 3 despite no param details in the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Start video recording' clearly states a verb ('start') and a resource ('video recording'), which distinguishes it from siblings like browser_take_screenshot or browser_stop_video. However, it lacks specificity about what is being recorded (e.g., browser tab, entire screen) and context about the recording scope, making it only adequate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like browser_start_tracing or browser_take_screenshot. It does not mention prerequisites, typical use cases, or exclusions (e.g., video vs. screenshot vs. tracing), leaving the agent to infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/Pelag-Michael/Chrome-for-AI'
If you have feedback or need assistance with the MCP directory API, please join our Discord server