agent-recorder-mcp

Overview Schema Source Related Servers Discussions Admin

Startrecording

startRecording

Starts recording the agent's display before browser or computer-use actions, so the session can be captured to an MP4 file and shared later via a replay link.

Instructions

Start recording the agent computer display before browser or computer-use actions.

Call this before the first browser or computer action. The display is selected from this agent process tree. A display belonging to another session is not used.

fps defaults to 5. maxDurationSeconds defaults to 7200. When the limit is reached the capture stops and the file is kept so finishRecording can still share it.

title, when supplied, names the MP4 using the agent's local start time: YYYY-MM-DD_HHMM_title.mp4 (e.g. 2026-11-04_1408_github-login.mp4). Unsafe filename characters are converted to hyphens. A duplicate filename gets a -2, -3, etc. suffix, never overwriting an earlier recording. If title is omitted, the legacy unique recording ID filename is used.

outputDir writes the recording file directly into that directory. Omit it to use the default recordings directory. The directory must already exist and be writable. When the replay will be uploaded with a connected Google Drive tool, pass a directory that tool can read, such as /workspace.

If a recording is already active, or is waiting to be shared, that recording is returned and a second recorder is not started. title and outputDir are ignored in that case.

Input Schema

Name	Required	Description	Default
`fps`	No
`title`	No
`outputDir`	No
`maxDurationSeconds`	No

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedv0.2.3Nov 5, 2026

addedInput schema / properties / outputDir

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null
+}

addedInput schema / properties / title

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null
+}

First observedv0.1.0Oct 5, 2026

TDQS

A4.7/5.0

Behavior4/5

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

With no annotations, the description carries the full burden and does so well: it discloses idempotency (a second recorder is never started), the auto-stop at maxDurationSeconds with the file retained, filename derivation/sanitization/collision suffixing, and the requirement that outputDir pre-exist and be writable. It stops short of stating error behavior when outputDir is invalid, whether user consent or permissions are needed, and roughly how large the output can get.

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 the imperative call-to-action, then organized into short paragraphs per concern (duration, title, outputDir, already-active case), which makes it easy to scan. It runs longer than necessary for four optional parameters — the process-tree/other-session sentences and some filename detail could be tightened — but nearly every sentence carries usable information.

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 four-parameter, zero-required side-effecting tool with no annotations, the description covers timing, defaults, termination, naming, path requirements, and idempotency. Because an output schema exists, omitting return-value details is appropriate and nothing an agent needs to invoke it safely is missing.

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

Parameters5/5

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

Schema description coverage is 0%, so the description must compensate and largely does: it gives the fps and maxDurationSeconds defaults, explains what happens at the duration limit, and fully specifies title (naming pattern with example, unsafe-character conversion, -2/-3 dedup) and outputDir (must exist, must be writable, Drive-readable path suggestion, plus being ignored when a recording is already active). Only fps lacks range or tuning guidance, which is a small residual gap.

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 the agent computer display') plus the exact moment to do it ('before browser or computer-use actions'). The scope clause about the display being selected from this agent process tree further distinguishes it from sibling tools like recordingStatus and finishRecording.

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?

Explicitly says when to call it ('Call this before the first browser or computer action') and implicitly when not to bother, since an already-active or pending recording is returned rather than starting a second one. It also routes downstream behavior by naming finishRecording as the consumer of the retained file, and gives a conditional case for choosing outputDir when a Google Drive upload tool is involved.

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

Deploy Server