download_tweet_video

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

Since no annotations are provided, the description carries the full transparency burden. It discloses dependency requirements (yt-dlp, ffmpeg), default output directory, format selection behavior (with ffmpeg requirement for 'bestvideo+bestaudio'), and failure modes (raises ToolError if yt-dlp/ffmpeg missing, no video, or download fails). This is comprehensive behavioral disclosure beyond the schema.

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 structured into a one-sentence summary, a parameter list, and a returns/errors section. It is moderately sized but every sentence provides useful information—no filler. The clear formatting (Args/Returns) makes it easy to scan and understand.

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?

The tool has moderate complexity (external dependencies, multiple parameters, formatting options, error conditions). The description covers the purpose, all parameters with defaults, return JSON fields, and error scenarios. It also notes when ffmpeg is required. This is complete for the tool's complexity, and the output schema further supplements the return type details.

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?

The input schema provides only titles and types with zero descriptions. The description compensates fully by explaining each parameter: tweet_id accepts numeric ID or URL, output_dir has a default from environment variable or fallback path, and format defaults to 'best[ext=mp4]' with explanation of when to use 'bestvideo+bestaudio'. This adds substantial meaning beyond the bare schema, which is especially critical given 0% schema description coverage.

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 opens with 'Download video(s) attached to a tweet via yt-dlp', which clearly identifies the action (download), the resource (videos attached to a tweet), and the method (yt-dlp). This is a specific verb+resource statement that distinguishes this tool from all sibling tools, none of which handle video downloads.

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 states the exact use case—downloading videos from a tweet—which is clear context for when to use the tool. It does not explicitly mention alternatives or when not to use it, but given the tool's unique functionality among siblings, the implied usage is sufficient. No exclusions or contradictory guidance are present.

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