extract_audio_and_metadata

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

With no annotations, the description usefully discloses that audio extraction is enabled by default, creates a standalone file, and returns a JSON string. It does not clarify default output naming or location, overwrite behavior, or whether the source media is left unchanged.

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 purpose is front-loaded, followed by compact Args and Returns sections that are easy to scan. There is no unnecessary wording, and the parameter detail is valuable given the undocumented schema.

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 description supplies enough operational and parameter information for correct invocation of this relatively simple tool, while the output schema reduces the need for further return-value documentation. Default destination and file-handling behavior remain minor but useful omissions.

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?

Despite 0% schema description coverage, the Args section documents all four parameters, including the extraction default and supported audio formats. The main remaining ambiguity is what destination is used when output_audio_path is omitted.

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 opening sentence clearly states both operations: retrieving media metadata such as FPS, resolution, bitrate, and codecs, and optionally extracting audio. This scope is readily distinguishable from the editing-oriented sibling tools.

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 establishes a clear use case for media inspection and optional audio ripping, and explains that extract_audio controls whether a standalone audio file is produced. It does not provide explicit exclusions or alternatives, but none are essential among the listed siblings.

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