start_recording

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

There are no annotations, so the description carries the full behavioral disclosure burden. It does so thoroughly by saying the call returns immediately, recording continues in the background, only one recording can exist, and the return includes the file path and the PID of the helper process keeping it alive.

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 well structured and front-loaded: it opens with the core behavior, then provides a compact Args section and a Returns note. Every sentence contributes meaningful information with no filler or redundancy.

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?

For an asynchronous operation with no annotations or output schema, the description is highly complete. It explains when to call it, how it runs, when it stops, what parameters matter, and what the return value contains. The only omitted detail is error behavior when a recording already exists, but the single-recording constraint makes that outcome interpretable.

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 0%, but the description compensates completely: output is explained with .webm, default timestamped location, and the '%' restriction; framerate is given units; draw_cursor behavior is described; and area is defined as [x, y, width, height] pixels with a full-screen default.

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 first sentence clearly states the operation: it starts a screen recording and returns immediately. It also frames the recording's lifecycle relative to stop_recording, making it distinct from the sibling tools stop_recording and recording_status.

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 strong lifecycle guidance: the recording continues in the background until stop_recording is called, and only one recording can exist at a time. It does not explicitly mention when to prefer recording_status over start_recording, so it falls just short of full alternative-routing guidance.

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