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

With no annotations provided, the description carries the full behavioral burden. It signals a read-only listing action through 'Lists available' and adds useful category semantics, but it does not explicitly confirm that no side effects occur or describe the shape of the returned preset entries.

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?

Two sentences, with the core action front-loaded, followed by the category distinction and downstream usage guidance. Every sentence earns its place 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 a simple list tool with two optional parameters and no output schema, the description provides the essential context: what is listed, how presets are categorized, and how they are used with transcribe_with_preset. Explicit return-field details would be a nice addition, but the tool's straightforward nature makes the description sufficient.

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 schema already documents both parameters at 100% coverage, but the description adds richer meaning for the enum values: 'style' modifies tone/voice without changing structure, while 'format' restructures content into a specific document type. This goes beyond the schema's brief enum comments, though it adds no detail about the filter parameter's syntax.

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 a specific verb ('Lists') and a defined resource ('available transcription presets from the Text-Transformation-Prompt-Library'), then clarifies the two preset categories. This clearly differentiates it from the transcribe_* sibling tools, which perform audio transcription rather than preset listing.

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 explicitly tells the agent to use the listed presets with the transcribe_with_preset tool, establishing the expected workflow. It does not enumerate when-not-to-use or compare against each transcribe_* sibling, but the list-vs-transcribe distinction is clear from the tool names.

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

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

With no annotations provided, the description carries the burden of behavioral disclosure. It adds useful context: large files are automatically compressed, formats are auto-converted, and the output is processed (filler removed, punctuation added). It also implies a network call via OpenRouter. This goes beyond the schema, though it omits details like cost or latency.

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 tightly written with no filler. The main purpose and output behavior are front-loaded, followed by format support and the default-tool recommendation. Every sentence contributes value.

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?

Despite having 10 parameters and no output schema, the description is reasonably complete when combined with the rich schema. It explains core behavior and the default status, while the schema documents each parameter, including transport preferences (file_url vs file_content) and output_dir behavior. Minor gaps like explicit mention of saving behavior could be added, but overall it is sufficient for a tool of this complexity.

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 100%, so the baseline is 3. Every parameter is well-documented in the schema itself, and the description adds little parameter-specific meaning beyond overall behavioral hints like 'large files are automatically compressed'.

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 identifies the verb 'transcribes an audio file' and specifies the resource, along with the output transformation ('lightly edited transcript with filler words removed, verbal corrections applied, punctuation added, and paragraph breaks inserted'). It also positions itself as the 'recommended default tool', distinguishing it from siblings like transcribe_audio_raw or transcribe_with_preset.

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?

Explicitly states it is the recommended default tool, giving clear context for when to choose it. However, it does not name specific alternatives or exclusions, so it stops short of full when/when-not guidance.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions that transcription runs through Gemini via OpenRouter and uses a custom prompt, but it does not disclose side effects like saving to output_dir, how audio is supplied, return behavior, or any limitations. This is a significant gap for an 11-parameter tool.

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 two sentences with no filler. The primary purpose is front-loaded first, and the usage guidance follows immediately. Every sentence earns its place.

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 11 parameters, no annotations, and no output schema, the description is too thin to be contextually complete. It does not explain what a successful call returns, whether a transcript file is saved, or how the audio transport options relate. The rich schema helps, but the description still leaves important operational context unstated.

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 has 100% parameter coverage with detailed descriptions, so the description does not need to restate parameter meanings. It adds the general concept of a custom prompt, but this is already captured by the custom_prompt parameter schema. Baseline 3 is appropriate.

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 a specific action — transcribing an audio file — and the differentiator: a user-defined custom prompt. It distinguishes this tool from siblings by emphasizing full control over processing/formatting and positioning it as the option for instructions not covered by other 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 explicitly says to use this tool when specific transcription instructions are needed and not covered by other tools. It provides clear context but does not name sibling alternatives or state when not to use it, so it falls just short of full exclusion guidance.

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

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

With no annotations, the description carries the full disclosure burden, yet it only restates the core function and freeform nature. It does not explain return behavior, whether/when files are saved, validation of format strings, or any limitations of the ad-hoc path.

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?

Three short sentences, all informative: purpose, freeform capability, and usage routing. No fluff or redundancy; front-loaded effectively.

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 handles purpose and one sibling choice, and the rich schema documents all 11 parameters. However, with no output schema and no annotations, the missing return-value/side-effect information and lack of guidance for the other sibling tools leave notable gaps.

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 coverage is 100%, so the baseline is 3. The description's 'freeform format' note is already present in the format parameter's schema, so it adds no additional semantic value beyond what the input schema provides.

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 identifies the action (transcribe an audio file and format the output) and the resource (audio file), and explicitly contrasts with transcribe_with_preset. However, with several transcription siblings (transcribe_audio, transcribe_audio_raw, transcribe_audio_custom), it does not fully differentiate from all of them, leaving some ambiguity.

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?

It gives an explicit use case ('quick ad-hoc format without browsing presets') and directs agents to transcribe_with_preset for curated formatting. This is actionable, but it does not address when to use transcribe_audio, raw, or custom variants, so the routing guidance is incomplete.

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

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

With no annotations, the description carries the full burden, and it does disclose a key behavioral trait: the output is verbatim with no cleanup, preserving filler words, false starts, and repetitions. It also reveals the underlying model provider. However, it does not describe how the transcript is returned (e.g., text output vs. saved file), error behavior, or transport-related edge cases, leaving some behavioral ambiguity.

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 two sentences with zero filler. The primary function and the key 'no cleanup' differentiator are front-loaded, and the usage guidance is concise. Every sentence earns its place.

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?

This is a complex tool with 10 parameters, multiple file transport options (file_url, ssh, file_content), and five sibling tools, yet the description gives no guidance on choosing between these transports or explaining the output format/saving behavior. The schema covers parameter syntax but not how to decide among the three mutually exclusive source options. For the tool's complexity, the description is under-specified.

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 100%, so the baseline is 3. The description itself adds no parameter-level meaning beyond the schema; it only mentions audio file generically. With all ten parameters already well-documented in the schema, this is acceptable, and the description neither compensates nor detracts.

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 verb 'Transcribes', the resource (audio file), and the underlying provider (Gemini via OpenRouter). It also highlights the distinguishing output trait: a verbatim transcript with NO cleanup, preserving filler words and repetitions. However, it does not explicitly identify how this differs from sibling tools like transcribe_audio or transcribe_with_preset, leaving some differentiation to inference from the 'raw' name.

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 clear usage context: 'Use this when you need exact speech-to-text without any editing.' This tells the agent when to choose this tool. It does not discuss when NOT to use it or recommend alternatives, so it stops short of the full 5-level guidance.

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

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

No annotations are provided, so the description carries the full behavioral burden. It reveals the core transformation behavior and preset categories, but omits important operational details like return format, what happens when no output_dir is provided, failure modes, or any side effects.

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 densely informative, with the core action front-loaded and preset categories clearly organized. The examples and pointer to list_transcription_presets all earn their place, though the example lists are slightly longer than strictly necessary.

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 complexity (11 parameters, no annotations, no output schema), the description plus schema provide a mostly viable picture. The main gap is the absence of explicit output/return behavior and lack of guidance for choosing this over similar sibling tools, but the extensive schema descriptions compensate for much of the missing context.

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 already provides 100% parameter coverage with detailed descriptions, giving a baseline of 3. The description adds extra meaning for the preset parameter by explaining the style/format taxonomy and providing concrete examples, which helps an agent select an appropriate preset.

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 a specific action and resource: transcribes audio and applies a curated preset to transform the output. It adds a useful style/format taxonomy, but it does not explicitly distinguish itself from sibling tools like transcribe_audio_format or transcribe_audio_custom, so it falls just short of full differentiation.

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 implies this tool should be used when a preset-based transcription is desired, and it explicitly directs users to list_transcription_presets for preset discovery. However, it never states when not to use this tool or names alternatives such as transcribe_audio_raw or transcribe_audio_custom.

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