export_screencast_mp4

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

With no annotations, the description carries the full burden of transparency. It explains that fps is the playback rate (not capture rate) and that ffmpeg is required, which are useful behavioral details. However, it does not describe the behavior when parameters are omitted (e.g., default output_path) or the outcome of the operation (e.g., file creation location, overwrite behavior).

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 three sentences, front-loaded with the main purpose. It adds relevant detail (default pattern, fps note, ffmpeg requirement) without unnecessary fluff. It could be slightly more concise by combining the first two sentences, but overall it is well-structured.

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 simplicity and the presence of an output schema (which may document return value), the description covers core usage and dependencies. However, it lacks details on default output behavior, error conditions (e.g., missing ffmpeg), and performance considerations. These gaps make it adequate but not fully comprehensive.

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%, meaning the description should compensate. It only partially explains the fps parameter (playback vs. capture rate). The frames_dir parameter is only mentioned as a location but not described (e.g., required, absolute/relative path). output_path is not described at all. This leaves the agent unclear on essential parameter semantics.

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 clearly states the tool's purpose: 'Stitch screencast frames in frames_dir into an mp4.' It uses a specific verb ('stitch') and resource ('frames... into an mp4'), and it implicitly distinguishes from sibling tools like start_screencast (which captures frames) and stop_screencast (which stops capture).

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 indicates that the tool uses the default frame pattern written by start_screencast, implying start_screencast should be used first. It also states the ffmpeg prerequisite. However, it does not explicitly list conditions for when not to use this tool or suggest alternatives (e.g., using a different format).

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