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

Annotations indicate this is a non-read-only, non-destructive, non-idempotent, closed-world operation. The description adds that it 'triggers' an action and specifies it's for 'mix on/off air', which provides context about the transition effect. However, it doesn't disclose additional behavioral traits like whether it requires specific device states, has rate limits, or what happens on failure. With annotations covering basic safety, the description adds some value but not rich behavioral context.

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 appropriately sized with two sentences: one stating the purpose and effect, and another listing parameters. It's front-loaded with the core functionality. However, the Args section is redundant with the schema, slightly reducing efficiency. Every sentence serves a purpose, but there's minor waste in repeating schema information.

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 moderate complexity (triggering a transition with one parameter), annotations provide basic safety info, and the schema fully covers inputs. However, there's no output schema, and the description doesn't explain return values or error conditions. For a non-read-only tool that performs an action, more context on outcomes would be helpful. The description is minimally adequate but has gaps in completeness.

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% description coverage, fully documenting the single parameter 'dsk' with its type, range, and meaning. The description repeats this parameter info verbatim in the Args section, adding no additional semantic context beyond what the schema already provides. According to the rules, when schema coverage is high (>80%), the baseline score is 3 even with no extra param info in the description.

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 specific action ('Trigger an auto transition') and the target resource ('for a downstream keyer'), with additional clarification about what the transition does ('mix on/off air'). This distinguishes it from sibling tools like 'atem_auto_transition' (which appears to be for main transitions) and 'atem_set_dsk_on_air' (which likely sets state rather than triggering a transition).

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 usage context through the phrase 'mix on/off air', suggesting this tool is for toggling a downstream keyer's on-air status via an auto transition. However, it doesn't explicitly state when to use this versus alternatives like 'atem_set_dsk_on_air' or 'atem_cut', nor does it mention prerequisites (e.g., needing a configured downstream keyer). The guidance is implied but not explicit.

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?

Annotations already indicate this is a non-readonly, non-destructive, non-idempotent action. The description adds useful context about using 'current transition settings' and the preview-to-program flow, but doesn't disclose potential side effects (e.g., on-air changes), rate limits, or authentication needs. No contradiction with annotations.

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: first states purpose clearly, second documents the single parameter. Efficient and front-loaded, though the Args section is somewhat redundant given the schema. 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?

For a single-parameter action tool with full schema coverage and annotations covering safety profile, the description is adequate. However, without an output schema, it doesn't explain what happens after triggering (e.g., success confirmation, error conditions). Could benefit from more behavioral 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?

Schema description coverage is 100%, so the schema fully documents the 'me' parameter. The description's Args section repeats the schema info without adding meaningful semantics beyond it. Baseline 3 is appropriate when schema does the heavy lifting.

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 specific action ('trigger an auto transition'), specifies the transition types ('dissolve, wipe, etc.'), and defines the scope ('from preview to program using current transition settings'). It distinguishes from siblings like 'atem_cut' (immediate cut) and 'atem_preview_and_auto' (sets preview then auto transitions).

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 usage when wanting to execute a transition with current settings, but doesn't explicitly state when to use this vs. alternatives like 'atem_cut' (for immediate cuts) or 'atem_set_transition_position' (for manual control). No explicit exclusions or prerequisites are mentioned.

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?

Annotations indicate this is a non-destructive, idempotent operation with open-world semantics, which the description doesn't contradict. The description adds valuable context beyond annotations: it specifies the default port (9910) and mentions that it returns connection confirmation with model info, which helps the agent understand the tool's behavior and expected outcomes.

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 front-loaded with the core purpose in the first sentence, followed by a structured 'Args' and 'Returns' section that efficiently covers key details without redundancy. Every sentence serves a clear purpose, making it highly concise and well-organized for quick comprehension.

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 moderate complexity (network connection with two parameters), rich annotations, and no output schema, the description is fairly complete. It covers the purpose, parameters, and return info, though it could benefit from more behavioral context (e.g., error handling, network timeouts) to fully guide the agent in a production environment.

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?

With 100% schema description coverage, the input schema already fully documents both parameters (host and port). The description adds minimal value beyond the schema, only restating the IP address example and default port. This meets the baseline of 3 since the schema handles the heavy lifting, but no additional semantic insights are provided.

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 action ('Connect to') and target resource ('Blackmagic ATEM video switcher on the network'), making the purpose immediately understandable. However, it doesn't explicitly differentiate from its sibling 'atem_disconnect', which handles disconnection, though the distinction is implied by the verb 'Connect'.

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 usage context by specifying it's for connecting to a network device, but provides no explicit guidance on when to use this tool versus alternatives (e.g., prerequisites, timing relative to other operations like 'atem_get_status'). It doesn't mention any exclusions or direct alternatives, leaving usage somewhat open-ended.

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?

Annotations already cover key behavioral traits (non-readOnly, non-destructive, non-idempotent, non-openWorld). The description adds context about the transition being 'hard' and 'instant', which clarifies the action beyond annotations, but doesn't detail side effects like on-air changes or rate limits.

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 front-loaded with the core purpose in the first sentence, followed by a brief parameter note. It's appropriately sized with no wasted words, though the parameter section could be slightly more integrated for optimal flow.

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 moderate complexity (a single optional parameter) and lack of output schema, the description is adequate but could benefit from more context on effects (e.g., immediate on-air change) or error conditions, as annotations don't fully cover behavioral nuances.

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%, with the schema fully documenting the 'me' parameter. The description adds minimal value by noting it's optional with a default, but doesn't provide additional meaning beyond what's in the schema, aligning with the baseline for high 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 clearly states the tool's purpose with specific verb ('perform a hard cut transition') and resource ('preview to program'), distinguishing it from siblings like 'atem_auto_transition' or 'atem_set_transition_style' which imply different transition types or configurations.

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 usage for instant switching from preview to program, but provides no explicit guidance on when to use this vs. alternatives like 'atem_auto_transition' or 'atem_set_transition_style', nor does it mention any prerequisites or exclusions.

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?

Annotations provide key behavioral hints (non-readOnly, non-destructive, idempotent), but the description adds valuable context by specifying it disconnects from an existing connection. It doesn't contradict annotations and clarifies the precondition, though it could mention side effects like terminating ongoing operations.

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 a single, front-loaded sentence that directly states the tool's function without any redundant or unnecessary information. Every word contributes to understanding, making it highly efficient and 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 (0 parameters, no output schema) and rich annotations, the description is mostly complete. It covers the core action and precondition, but could slightly enhance completeness by noting idempotency or effects on sibling tools, though annotations partly address this.

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 0 parameters with 100% coverage, so no parameter documentation is needed. The description appropriately doesn't discuss parameters, maintaining focus on the tool's purpose. A baseline of 4 is applied since it handles the zero-parameter case effectively.

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 specific action ('Disconnect') and resource ('currently connected ATEM switcher'), distinguishing it from all sibling tools which perform different operations like connecting, controlling, or querying the switcher. It precisely defines what the tool does without 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?

The description explicitly indicates when to use this tool: when there is a 'currently connected ATEM switcher' to disconnect from. It implies an alternative (using 'atem_connect' to connect instead) and excludes use when no connection exists, providing clear contextual 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?

Annotations cover basic hints (non-readOnly, non-destructive, etc.), but the description adds valuable behavioral context: it's a toggle with state-dependent behavior (fades to black if live, fades back up if already in FTB). This goes beyond annotations by explaining the dual-state operation, though it doesn't mention rate limits or specific permission needs.

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 with a clear purpose statement followed by parameter details. It's appropriately sized (two sentences plus Args), though the Args section could be integrated more seamlessly. Every sentence adds value without 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?

Given the tool's moderate complexity (stateful toggle), annotations provide safety hints, and schema fully covers the single parameter. The description explains the core behavior well, though it lacks output details (no output schema) and doesn't mention error cases or visual feedback. It's mostly complete for a toggle operation.

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% with clear documentation of the 'me' parameter. The description's Args section repeats the schema info without adding extra meaning (e.g., why ME matters, typical use cases). Baseline 3 is appropriate since the schema does the heavy lifting.

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 specific action: 'Toggle Fade to Black (FTB)' with precise behavior: 'If currently live, fades to black. If already in FTB, fades back up.' It distinguishes from siblings like 'atem_cut' (instant transition) and 'atem_auto_transition' (auto fade) by specifying toggle behavior.

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 usage context through 'Toggle Fade to Black' and the conditional logic, but doesn't explicitly state when to use this vs. alternatives like 'atem_cut' or 'atem_auto_transition'. No explicit exclusions or prerequisites are provided.

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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering safety and idempotency. The description adds value by specifying the scope ('all input levels, mix options, and master output settings') and return format ('JSON object'), which are not covered by annotations. No contradiction with annotations.

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 zero waste: the first states the purpose and scope, the second specifies the return format. It is front-loaded with the core functionality and efficiently 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 has no parameters, rich annotations covering safety, and no output schema, the description is mostly complete. It specifies what is returned, but could benefit from more detail on the JSON structure or example output. However, it adequately covers the core functionality for a read-only tool.

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 tool has 0 parameters with 100% schema description coverage, so no parameter documentation is needed. The description appropriately does not discuss parameters, focusing instead on what the tool returns. Baseline is 4 for 0 parameters.

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 'Get' and the resource 'current audio mixer state', specifying it includes 'all input levels, mix options, and master output settings'. It distinguishes from siblings like 'atem_get_status' by focusing specifically on audio mixer state rather than general 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 implies usage when audio mixer state is needed, but does not explicitly state when to use this tool versus alternatives like 'atem_get_status' or 'atem_set_audio_master_output'. No exclusions or prerequisites are mentioned, leaving usage context somewhat ambiguous.

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?

Annotations already indicate read-only, non-destructive, and idempotent behavior, so the description adds value by specifying the return format ('JSON object mapping each aux output to its current source input'). It does not disclose rate limits or auth needs, but with annotations covering safety, this is sufficient for good transparency.

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, front-loaded with the purpose and followed by return details. Every sentence adds essential information without redundancy, making it highly efficient and 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 (0 parameters, no output schema) and rich annotations, the description is mostly complete. It covers purpose and return format but could benefit from more explicit usage guidelines or error handling details, though not critical for this low-complexity tool.

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 tool has 0 parameters with 100% schema description coverage, so no parameter documentation is needed. The description does not add param details, but this is appropriate given the lack of inputs, warranting a baseline score of 4 for adequate handling.

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 'Get' and the resource 'current source routing for all auxiliary outputs', specifying the exact scope. It distinguishes from siblings like 'atem_set_aux_source' by focusing on retrieval rather than modification, making the purpose specific and unambiguous.

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 usage for retrieving current routing information, which is clear in context. However, it does not explicitly state when to use this tool versus alternatives like 'atem_get_status' or 'atem_get_audio_state', nor does it mention prerequisites or exclusions, leaving some guidance gaps.

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?

Annotations cover key behavioral traits (read-only, non-destructive, idempotent, closed-world), so the description's burden is lower. It adds value by specifying the scope ('recording and streaming status'), but does not disclose additional context like rate limits, error conditions, or what 'status' entails beyond the annotations.

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 a single, efficient sentence that directly states the tool's purpose without any fluff. It is front-loaded and every word contributes to understanding, making it highly concise and 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 (0 parameters, annotations provided, no output schema), the description is adequate but minimal. It lacks details on return values or error handling, which could be helpful for an agent, though annotations reduce the need for extensive explanation.

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?

With 0 parameters and 100% schema description coverage, the baseline is high. The description does not need to explain parameters, and it appropriately focuses on the tool's function without redundant details, earning a near-perfect score for clarity in a parameterless context.

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 action ('Get') and the specific resource ('current recording and streaming status from the ATEM'), making the purpose evident. However, it does not explicitly differentiate from sibling tools like 'atem_get_status' or 'atem_get_audio_state', which might provide overlapping status information, so it falls short of a perfect score.

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 no guidance on when to use this tool versus alternatives. With siblings like 'atem_get_status' and 'atem_start_recording', there is no indication of context, prerequisites, or exclusions, leaving the agent to infer usage based on tool names alone.

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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering safety and idempotency. The description adds valuable context by specifying what information is returned (model, firmware, inputs, connection state) and that it returns a JSON object, which isn't covered by annotations. No contradictions with annotations.

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 that are front-loaded with the core purpose and follow with return details. Every sentence adds value: the first defines the scope, the second specifies the return format and content. No wasted words 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 read-only, idempotent tool with no parameters and no output schema, the description is mostly complete. It covers what the tool does and what it returns. However, it doesn't mention potential errors (e.g., if not connected) or usage context, leaving minor gaps given the tool's simplicity.

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 tool has 0 parameters with 100% schema description coverage, so no parameter documentation is needed. The description appropriately doesn't discuss parameters, focusing instead on the return value. Baseline for 0 parameters is 4, as it efficiently handles the lack of inputs.

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 specific action ('Get current ATEM switcher status') and resource ('ATEM switcher'), listing the exact information returned. It distinguishes from siblings like 'atem_get_audio_state' or 'atem_get_transition_state' by specifying it provides overall status including model info, program/preview inputs, and connection state.

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 usage for retrieving current switcher status, but doesn't explicitly state when to use this tool versus alternatives like 'atem_get_audio_state' or 'atem_get_transition_state' for more specific status checks. No guidance on prerequisites (e.g., connection state) or exclusions is provided.

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?

Annotations already indicate read-only, non-destructive, and idempotent behavior, which the description aligns with by using 'Get'. The description adds valuable context beyond annotations by specifying the return format ('JSON with current transition style, rates per type, and whether a transition is currently in progress') and the default parameter value, enhancing transparency without contradiction.

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 front-loaded with the core purpose in the first sentence, followed by a structured 'Args' and 'Returns' section. Every sentence adds specific value without redundancy, making it efficient and well-organized for quick comprehension.

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 low complexity (one optional parameter), rich annotations covering safety, and no output schema, the description is largely complete. It explains what the tool does, the parameter, and the return format. A slight gap exists in not detailing potential error cases or system-specific constraints, but it suffices for basic use.

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%, with the schema fully documenting the 'me' parameter. The description adds minimal value beyond the schema by mentioning the default value (0 for ME1) and implying the parameter's optionality, but does not provide additional semantic details. This meets the baseline for high schema 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 clearly states the tool's purpose with specific verbs ('Get current transition settings') and resources ('for a Mix Effect bus'), including what information is retrieved ('style, rates, and in-transition status'). It distinguishes itself from siblings like atem_set_transition_style or atem_set_transition_rate by focusing on retrieval rather than modification.

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 usage when needing to check transition settings, but does not explicitly state when to use this tool versus alternatives like atem_get_status or other get_* tools. It provides clear context by specifying the target (Mix Effect bus) but lacks explicit exclusions or named alternatives.

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?

Annotations already indicate read-only, non-destructive, and idempotent behavior, but the description adds valuable context by specifying the return format ('JSON array of macros with their index, name, and whether they are valid/used'). This clarifies what data is returned, which annotations do not cover. No contradiction with annotations exists.

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: the first states the purpose, and the second details the return format. Every sentence earns its place by providing essential information without redundancy, making it front-loaded and efficiently 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 (0 parameters, no output schema), the description is complete. It covers the purpose, output details, and behavioral context, which is sufficient for an agent to understand and invoke this tool correctly without needing additional explanation.

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?

With 0 parameters and 100% schema description coverage, the baseline is 4. The description does not need to explain parameters, and it appropriately focuses on the tool's output instead, adding value beyond the empty input schema.

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 ('List') and resource ('all defined macros on the ATEM switcher'), making the purpose specific and unambiguous. It distinguishes this tool from siblings like atem_macro_run, atem_macro_stop, and atem_macro_continue by focusing on listing rather than executing or controlling macros.

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 usage when needing to retrieve macro information, but does not explicitly state when to use this tool versus alternatives. It lacks guidance on prerequisites (e.g., whether the switcher must be connected) or exclusions, though the context of listing macros is clear from the purpose.

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?

Annotations indicate this is a non-read-only, non-destructive, non-idempotent operation, which the description aligns with by implying a state change (continuing). However, the description adds minimal behavioral context beyond annotations—it doesn't specify effects like whether it resumes from a pause point or requires specific conditions, though with annotations covering safety, this is acceptable but not rich.

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 a single, direct sentence with no wasted words, making it highly concise and front-loaded. Every word earns its place by clearly stating the action without 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?

Given the tool's complexity (a state-changing operation with no parameters) and lack of output schema, the description is minimally adequate. It states what the tool does but lacks details on behavior, prerequisites, or output, which could be helpful for an agent, though annotations provide some safety 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 has 0 parameters with 100% coverage, so no parameter documentation is needed. The description doesn't add param info, which is fine here, but it doesn't compensate for any gaps since there are none—baseline 4 is appropriate for zero parameters.

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 ('Continue') and resource ('a paused macro'), making the purpose specific and understandable. However, it doesn't explicitly differentiate from sibling tools like 'atem_macro_run' or 'atem_macro_stop', which would require more context about what distinguishes continuing from running or stopping a macro.

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 no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., that a macro must be paused first) or compare it to siblings like 'atem_macro_run' or 'atem_macro_stop', leaving the agent to infer usage from context alone.

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?

Annotations indicate this is a non-read-only, non-destructive, non-idempotent, closed-world operation. The description adds that it runs a macro by index, implying it triggers an action sequence, which aligns with annotations. However, it doesn't disclose additional behavioral traits like potential side effects, execution time, or error conditions beyond what annotations provide.

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 brief and front-loaded with the core purpose, followed by parameter details. It avoids unnecessary words, though the parameter explanation could be integrated more seamlessly rather than as a separate 'Args' section.

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 moderate complexity (executing a macro), lack of output schema, and rich annotations, the description is minimally adequate. It covers what the tool does but lacks details on return values, error handling, or interaction with other tools like 'atem_list_macros', leaving gaps for an agent to infer usage.

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%, with the schema fully documenting the 'index' parameter's type, range, and 0-based nature. The description repeats this information without adding meaningful context like macro slot mapping or execution consequences, so it meets the baseline for high schema 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 clearly states the action ('Run') and resource ('ATEM macro'), specifying it's executed by index number. It distinguishes from siblings like 'atem_macro_continue' and 'atem_macro_stop' by focusing on initiation, but doesn't explicitly differentiate from other macro-related tools beyond the 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?

No guidance is provided on when to use this tool versus alternatives like 'atem_macro_continue' or 'atem_macro_stop', nor does it mention prerequisites such as needing a connected ATEM device or macro availability. The description only states what it does, not when to use it.

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?

The description adds valuable context beyond annotations: it specifies that the tool stops a 'currently running' macro, which implies it only works when a macro is active. Annotations already indicate it's non-destructive, idempotent, and not read-only, but the description provides operational context that enhances understanding of when the tool is applicable.

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 a single, efficient sentence that front-loads the essential information ('Stop the currently running macro'). There is no wasted language, and it directly addresses the tool's purpose without unnecessary elaboration.

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, parameterless tool with annotations covering safety (non-destructive, idempotent) and no output schema, the description is complete enough. It specifies the action and context ('currently running'), though it could slightly enhance completeness by mentioning what happens after stopping (e.g., if the macro can be resumed).

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?

With 0 parameters and 100% schema description coverage, the baseline is 4. The description reinforces that no parameters are needed by focusing on the action ('Stop the currently running macro') without mentioning any inputs, which is appropriate and adds clarity for a parameterless tool.

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 specific action ('Stop') and target resource ('the currently running macro'), distinguishing it from siblings like atem_macro_continue and atem_macro_run. It uses precise language that directly conveys the tool's function without 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?

The description explicitly indicates when to use this tool: 'Stop the currently running macro.' This implies it should be used only when a macro is actively running, distinguishing it from alternatives like atem_macro_run (to start) or atem_macro_continue (to resume). The context is clear and specific.

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?

Annotations indicate this is a non-read-only, non-idempotent, non-destructive operation, which the description aligns with by describing a state-changing action. However, the description adds minimal behavioral context beyond annotations—it doesn't mention potential side effects, timing considerations, or error conditions. With annotations covering basic safety, a 3 is appropriate as the description adds some value but not rich behavioral details.

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 front-loaded with the core purpose in the first sentence, followed by a clear analogy. The parameter section is brief and directly relevant. Every sentence earns its place with no wasted words, making it easy to scan and understand quickly.

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 tool with two parameters, 100% schema coverage, and annotations covering basic behavioral hints, the description is reasonably complete. It explains the combined action and when to use it. However, without an output schema, it doesn't describe return values or potential errors, leaving a minor gap in full 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?

Schema description coverage is 100%, with both parameters ('input' and 'me') fully documented in the schema. The description repeats the parameter definitions verbatim from the schema without adding extra meaning or context. Baseline 3 is correct when the schema does the heavy lifting, though the description adds no additional semantic value.

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 specific action: 'sets a preview input then immediately triggers an auto transition to bring it on air.' It distinguishes from siblings like 'atem_set_preview' (only sets preview) and 'atem_auto_transition' (only triggers auto transition) by combining both operations. The analogy 'Equivalent to selecting a source and pressing AUTO' reinforces the purpose.

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 positions this as a 'Convenience tool' and names the equivalent manual action ('selecting a source and pressing AUTO'). This provides clear context for when to use it: when you want to both set preview and trigger an auto transition in one step, avoiding separate calls to sibling tools like 'atem_set_preview' and 'atem_auto_transition'.

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?

Annotations provide key behavioral hints (readOnlyHint=false, destructiveHint=false, idempotentHint=true), so the description doesn't need to repeat these. It adds some context by specifying what gets configured (master output level) but lacks details on side effects, error conditions, or rate limits. No contradiction with annotations exists.

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 appropriately sized with a clear main sentence followed by parameter details. It's front-loaded with the core purpose, though the Args section could be more integrated. No wasted sentences, but minor structural improvements are possible.

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 moderate complexity (2 optional parameters), rich annotations, and 100% schema coverage, the description is adequate but lacks output information (no schema provided) and deeper behavioral context. It covers the basics but doesn't fully compensate for the absence of output details or advanced usage scenarios.

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%, with both parameters well-documented in the schema (gain range, followFadeToBlack meaning). The description's Args section repeats this information without adding significant semantic value beyond the schema, such as explaining interactions between parameters or default behaviors.

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 specific action ('Configure') and resource ('master audio output level'), distinguishing it from sibling tools like 'atem_set_audio_mixer_input' which handles individual inputs rather than the master output. It precisely identifies what the tool does without being vague or tautological.

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 no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like 'atem_get_audio_state' for checking current settings or 'atem_fade_to_black' for related functionality, nor does it specify prerequisites or exclusions. Usage context is implied but not explicitly stated.

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?

Annotations indicate this is a non-readOnly, non-destructive, idempotent operation. The description adds valuable context beyond annotations by specifying that it configures 'built-in audio mixer' settings and explaining the behavioral meaning of 'afv' mode ('audio is live only when this input is on program'). However, it doesn't mention potential side effects like audio disruption during changes or whether changes persist across power cycles.

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 with a clear purpose statement followed by parameter details. Every sentence adds value: the first explains what the tool does, and the parameter section provides necessary context. However, the parameter section could be more concise since the schema already covers this information comprehensively.

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 configuration tool with 4 parameters, 100% schema coverage, and annotations covering safety aspects, the description provides adequate but minimal context. It explains the tool's purpose and the meaning of 'afv' mode, but lacks information about error conditions, what happens when optional parameters are omitted, or typical use cases. Without an output schema, some description of expected responses would be helpful.

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?

With 100% schema description coverage, the schema already fully documents all parameters with descriptions, ranges, and enum values. The description adds minimal value beyond the schema, only slightly elaborating on 'afv' mode. It doesn't provide additional context about parameter interactions, defaults for optional parameters, or practical usage examples.

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 specific action ('Configure an audio input'), the resource ('ATEM's built-in audio mixer'), and the specific properties being set ('gain, balance, and whether the input is on, off, or in audio-follow-video mode'). It distinguishes itself from sibling tools like 'atem_get_audio_state' (which reads audio state) and 'atem_set_audio_master_output' (which configures master output rather than individual inputs).

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 usage when configuring audio input properties on an ATEM mixer, but provides no explicit guidance on when to use this tool versus alternatives like 'atem_set_audio_master_output' for master output settings. It mentions the 'afv' mode context ('audio is live only when this input is on program'), which gives some situational awareness, but lacks explicit when/when-not recommendations or prerequisite information.

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?

The description adds valuable context beyond annotations: it explains the 0-based indexing convention for aux outputs, which is crucial for correct usage. Annotations already indicate this is a non-destructive, idempotent write operation, but the description reinforces the routing behavior without contradiction. No rate limits or auth needs are mentioned, but the annotations cover the essential safety profile.

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 perfectly structured: a clear purpose statement first, followed by parameter explanations with important implementation details (0-based indexing), then practical usage examples. Every sentence earns its place with no wasted words, and the information is front-loaded appropriately.

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 2-parameter routing tool with good annotations and full schema coverage, the description provides excellent context about what the tool does and when to use it. The only minor gap is the lack of output information (no output schema exists), but for a simple routing operation, the description is nearly complete. The practical examples compensate well for the missing output 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?

With 100% schema description coverage, the schema already fully documents both parameters. The description repeats the aux parameter's 0-based indexing but adds no additional semantic meaning beyond what's in the schema. The baseline of 3 is appropriate when the schema does all the parameter documentation work.

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 specific action ('Route an input source to an auxiliary output') and resource ('auxiliary output'), distinguishing it from siblings like atem_set_preview or atem_set_program which route to different outputs. It uses precise technical language appropriate for the domain.

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 context for when to use this tool ('Common uses: sending a clean feed to a recorder, routing a specific camera to a confidence monitor'), giving practical examples. However, it doesn't explicitly state when NOT to use it or mention specific alternatives among the sibling tools (e.g., atem_set_preview for preview bus routing).

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?

Annotations indicate this is a non-destructive, idempotent mutation tool (readOnlyHint: false, destructiveHint: false, idempotentHint: true). The description adds valuable context by explaining that DSKs 'overlay graphics (logos, lower thirds, etc.) on top of the program output,' which clarifies the tool's effect beyond the annotations. However, it does not mention rate limits, authentication needs, or error conditions.

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 front-loaded with the core purpose in the first sentence, followed by a brief explanation of DSKs, and then a clear Args section. Every sentence earns its place without redundancy, making it efficient and well-structured for quick understanding.

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 moderate complexity (2 parameters, mutation operation) and rich annotations (covering idempotency, destructiveness, etc.), the description is mostly complete. It explains what DSKs do and how to use the tool, but lacks output details (no output schema) and does not address potential side effects or error handling, which could be useful for an agent.

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%, with both parameters (dsk and onAir) fully documented in the schema. The description repeats this information in the Args section but adds no additional semantic context beyond what the schema provides, such as examples of when to toggle onAir or implications of dsk values. This meets the baseline for high schema 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 clearly states the specific action ('Put a downstream keyer on or off air') and resource ('DSKs overlay graphics on top of the program output'), distinguishing it from siblings like atem_set_dsk_sources (which sets sources) and atem_set_usk_on_air (which handles upstream keyers). It provides precise context about what DSKs are used for.

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 usage for controlling DSK on/off states but does not explicitly state when to use this tool versus alternatives like atem_auto_dsk (which may automate DSK operations) or atem_set_dsk_sources (which configures DSK content). No explicit exclusions or prerequisites are mentioned, leaving usage context inferred rather than clearly defined.

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?

Annotations indicate this is a non-destructive, idempotent write operation. The description adds context by specifying it sets sources for a 'downstream keyer', which clarifies the tool's domain. However, it doesn't mention rate limits, authentication needs, or side effects beyond what annotations cover, missing some behavioral details.

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 front-loaded with the core purpose in one clear sentence, followed by a structured parameter list. However, the parameter section duplicates schema information without adding value, slightly reducing efficiency. Overall, it's well-organized but could be more concise by omitting redundant details.

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 moderate complexity (3 parameters, no output schema), annotations cover safety and idempotency well. The description provides adequate purpose and parameter overview, but lacks details on error conditions, return values, or integration with sibling tools, leaving some gaps for full agent understanding.

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%, with all parameters documented in the schema. The description repeats the schema's parameter explanations verbatim ('fillSource (number, optional): Input to use as fill source'), adding no additional meaning or usage context beyond what's already structured.

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 specific action ('Set') and target resources ('fill and/or key sources for a downstream keyer'). It distinguishes from siblings like 'atem_set_dsk_on_air' (which controls on-air state) and 'atem_set_usk_sources' (which is for upstream keyers), providing precise 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 usage for configuring downstream keyer sources, but offers no explicit guidance on when to use this vs. alternatives like 'atem_set_usk_sources' or 'atem_set_dsk_on_air'. It lacks context about prerequisites or exclusions, leaving the agent to infer from tool names alone.

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?

Annotations indicate this is a non-destructive, idempotent write operation (readOnlyHint=false, destructiveHint=false, idempotentHint=true). The description adds value by specifying that it sets the 'preview (next) input,' clarifying it affects the preview bus rather than the program output, and references 'atem_set_program' for input ID consistency. It doesn't contradict annotations and provides useful context beyond them, though it could mention side effects like visual feedback on the switcher.

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 front-loaded with the core purpose in the first sentence, followed by a brief, structured 'Args' section. Every sentence earns its place by clarifying parameters without redundancy. It's appropriately sized for a simple tool, with zero waste, making it highly efficient and easy to scan.

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 moderate complexity (a write operation with two parameters), annotations cover safety and idempotency, and the schema fully describes inputs. The description adds context about the preview bus and input ID consistency. However, without an output schema, it doesn't explain return values (e.g., success confirmation or error details), leaving a minor gap. Overall, it's mostly complete but could benefit from output information.

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% description coverage, fully documenting both parameters ('input' and 'me') with details like ranges and defaults. The description adds minimal extra meaning, only noting that input IDs are 'same as atem_set_program' and 'me' is optional with a default. This aligns with the baseline score of 3, as the schema does the heavy lifting, and the description provides slight clarification without significant added value.

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 specific action ('Set the preview (next) input') and resource ('on the ATEM switcher'), using a precise verb. It effectively distinguishes this tool from siblings like 'atem_set_program' (which sets the program input) and 'atem_preview_and_auto' (which likely combines preview with auto-transition), making the purpose unambiguous and well-differentiated.

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 usage context by referencing 'preview (next) input' and relating input IDs to 'atem_set_program', suggesting it's for configuring the switcher's preview bus. However, it doesn't explicitly state when to use this tool versus alternatives (e.g., 'atem_preview_and_auto' or 'atem_set_program'), nor does it mention prerequisites like needing an active ATEM connection. The guidance is clear but lacks explicit exclusions or named alternatives.

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?

Annotations already provide key behavioral information (readOnlyHint=false, idempotentHint=true, destructiveHint=false). The description adds useful context about what 'program' means ('live/on-air') and provides concrete examples of input IDs, but doesn't disclose additional behavioral traits like error conditions, permission requirements, or rate limits that would be valuable beyond the annotations.

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 efficiently structured with a clear purpose statement followed by well-organized parameter documentation. Every sentence earns its place: the first establishes the core function, the Args section provides essential parameter context, and the Common input IDs section offers practical reference without 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 2-parameter mutation tool with good annotations but no output schema, the description provides adequate context. It explains what the tool does, documents parameters thoroughly with examples, and gives practical input ID references. However, it doesn't describe what happens on success/failure or return values, which would be helpful given the lack of output schema.

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?

With 100% schema description coverage, the baseline is 3. The description adds significant value by providing concrete examples of input values (e.g., '1=Input 1, 1000=Color Bars, 2001=Color 1') and clarifying the optional 'me' parameter's default behavior ('default: 0 for ME1'), which goes beyond the schema's basic descriptions.

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 specific action ('Set the program input') and identifies the target resource ('ATEM switcher'). It distinguishes itself from sibling tools like 'atem_set_preview' (which sets preview input) and 'atem_set_aux_source' (which sets auxiliary outputs) by focusing exclusively on the program/live output.

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 implicitly indicates when to use this tool (to change what's currently live/on-air) but doesn't explicitly state when NOT to use it or name specific alternatives. It provides context about the ATEM switcher environment but lacks explicit exclusion guidance compared to tools like 'atem_set_preview' for preview changes.

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?

Annotations cover key traits (readOnlyHint=false, destructiveHint=false, idempotentHint=true), but the description adds valuable context: it explains the manual nature of the operation ('like moving the T-bar') and the practical use case ('manual fades'), which helps the agent understand behavioral nuances beyond the structured hints.

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 front-loaded with the core purpose in the first sentence, followed by a concise 'Args' section. Every sentence earns its place by clarifying the tool's use and parameters without redundancy or fluff.

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 moderate complexity (manual transition control), annotations provide safety and idempotency info, and the schema fully documents parameters. The description adds context on usage and behavior, but lacks output details (no output schema) and could more explicitly differentiate from siblings, leaving minor 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 description coverage is 100%, with clear parameter documentation in the schema. The description's 'Args' section repeats this information without adding significant meaning beyond the schema (e.g., it restates the position range and ME default). This meets the baseline of 3 for high schema 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 clearly states the verb 'set' and the resource 'transition position', with the parenthetical 'like moving the T-bar' providing a concrete analogy. It distinguishes from sibling tools like 'atem_auto_transition' (automatic) and 'atem_set_transition_rate' (speed) by emphasizing manual control for fades.

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 states 'Useful for manual fades', providing clear context for when to use this tool. However, it does not specify when not to use it or name alternatives among siblings (e.g., 'atem_auto_transition' for automated transitions), which prevents a perfect score.

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?

Annotations already indicate this is a non-destructive, idempotent write operation (readOnlyHint=false, destructiveHint=false, idempotentHint=true). The description adds minimal behavioral context beyond this, such as clarifying the rate is in frames with examples (30fps=1 second), but doesn't mention side effects, error conditions, or confirmation of changes. With annotations covering the safety profile, a 3 is appropriate as the description adds some value but not rich behavioral details.

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 front-loaded with the core purpose in the first sentence, followed by a clear, bulleted list of parameters with helpful examples. Every sentence earns its place with no redundant or vague language, making it efficient and easy to parse.

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 moderate complexity (3 parameters, 2 required), 100% schema coverage, and annotations providing safety context, the description is adequate but lacks output information (no output schema) and doesn't fully address usage context or error handling. It's complete enough for basic use but leaves gaps for robust agent operation.

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 schema fully documents parameters. The description adds practical examples for the 'rate' parameter (e.g., '30 = 1 second at 30fps'), which clarifies semantics beyond the schema's technical definition. However, it doesn't explain the 'style' enum values or 'me' default implications in detail, keeping it from a perfect score.

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 specific action ('Set the transition duration/rate') and resource ('for a specific transition type'), distinguishing it from sibling tools like 'atem_set_transition_style' which configures style rather than rate. The verb 'Set' is precise and the scope is well-defined.

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 no guidance on when to use this tool versus alternatives like 'atem_set_transition_style' or 'atem_auto_transition'. It lacks context about prerequisites (e.g., needing to be connected via 'atem_connect') or typical workflows, leaving the agent to infer usage from tool names alone.

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?

Annotations already provide critical behavioral hints (readOnlyHint=false, destructiveHint=false, idempotentHint=true), but the description adds valuable context by specifying this applies to 'auto transitions' and listing the five specific style options. This clarifies the tool's scope beyond what annotations alone convey, though it doesn't mention side effects like visual changes or timing considerations.

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 perfectly structured with a clear purpose statement followed by a concise Args section. Every sentence earns its place, with no redundant information. The two-sentence format efficiently communicates essential information without unnecessary elaboration.

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 moderate complexity (2 parameters, one optional), comprehensive annotations, and full schema coverage, the description provides adequate context. It clearly states what the tool does and lists parameter options, though it doesn't explain return values (no output schema exists) or provide deeper guidance about transition behavior. For a configuration tool with good structured data, this is reasonably complete.

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?

With 100% schema description coverage, the input schema already fully documents both parameters (style with enum values, me with range and default). The description adds minimal value beyond the schema, merely restating the style options and default ME value without providing additional semantic context like what each transition style looks like or when to use specific ME values.

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 specific action ('Set the transition style') and resource ('for auto transitions'), with explicit enumeration of the five possible style values. It distinguishes this tool from siblings like 'atem_set_transition_position' and 'atem_set_transition_rate' by focusing specifically on style selection rather than position or rate adjustment.

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 usage context ('for auto transitions') but doesn't explicitly state when to use this tool versus alternatives like 'atem_auto_transition' or 'atem_cut'. No guidance is provided on prerequisites, timing, or exclusions, leaving the agent to infer appropriate usage from the tool name and description alone.

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?

Annotations provide idempotentHint=true and destructiveHint=false, which the description doesn't contradict. The description adds valuable context about USK applications and the default ME bus, enhancing understanding beyond annotations. However, it doesn't mention rate limits, error conditions, or visual feedback mechanisms.

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 efficiently structured with a clear purpose statement followed by parameter details. The first sentence effectively communicates the core functionality. However, the parameter section could be more integrated rather than a separate 'Args' block, and some redundancy exists with the 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?

For a mutation tool with good annotations (idempotent, non-destructive) and full parameter documentation, the description provides adequate context. It explains USK applications and the tool's role. The main gap is lack of output information (no output schema), but for a simple state-change operation, the description is reasonably complete.

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?

With 100% schema description coverage, the schema already documents all parameters thoroughly. The description's 'Args' section largely repeats schema information, adding only minor clarification about '0 = Key 1' for usk. This meets the baseline for high schema coverage without significant added value.

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 specific action ('Put an upstream keyer on or off air') and the target resource ('on a specific ME bus'), with additional context about USK applications. It distinguishes from siblings like atem_set_dsk_on_air (downstream keyer) and atem_set_usk_sources (configuring sources rather than on-air state).

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 usage for controlling USK on-air states but doesn't explicitly state when to use this versus alternatives. It mentions USK applications (picture-in-picture, etc.) which provides some context, but lacks explicit guidance on prerequisites, timing, or comparisons to other transition/keying tools.

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?

Annotations indicate this is a non-destructive, idempotent write operation (readOnlyHint=false, destructiveHint=false, idempotentHint=true). The description adds no behavioral context beyond this, such as rate limits, error conditions, or effects on other system states. With annotations covering core traits, the description meets a baseline but adds minimal extra value.

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 front-loaded with the core purpose in one sentence, followed by a structured 'Args' list. It avoids redundancy but could be more concise by integrating parameter details into the main text or omitting the schema-repetitive 'Args' section, as it doesn't add unique 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?

Given the tool's moderate complexity (4 parameters, no output schema), annotations provide safety and idempotency info, but the description lacks usage context, error handling, or examples. It's minimally adequate but leaves gaps in operational guidance, especially for a write tool with no output schema to clarify results.

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%, with all parameters documented in the schema (e.g., 'me' as 'Mix Effect bus', 'usk' as 'Upstream keyer number'). The description's 'Args' section repeats this information without adding meaning, syntax examples, or constraints beyond the schema, so it meets the baseline for high schema 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 clearly states the verb ('Set') and resource ('fill and/or cut sources for an upstream keyer'), specifying the exact action and target. It distinguishes from siblings like 'atem_set_usk_on_air' (which controls on-air state) and 'atem_set_dsk_sources' (which targets downstream keyers), providing precise 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?

No guidance is provided on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing an upstream keyer configured), exclusions, or comparisons to similar tools like 'atem_set_dsk_sources' for downstream keyers, leaving the agent without contextual usage cues.

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?

The description adds valuable behavioral context beyond annotations: it specifies hardware prerequisites (USB storage) and model limitations. Annotations already indicate this is a non-destructive, idempotent operation (readOnlyHint: false, destructiveHint: false, idempotentHint: true), but the description provides practical constraints not covered by annotations.

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 perfectly concise with two sentences that each earn their place: the first states the core action and prerequisite, the second adds model capability information. No wasted words, front-loaded with the main purpose.

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 zero-parameter tool with comprehensive annotations, the description is mostly complete. It covers prerequisites and constraints well. The only minor gap is not explicitly mentioning what happens when recording is already active (though idempotentHint suggests it's safe to call repeatedly).

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?

With 0 parameters and 100% schema description coverage, the baseline would be 4. The description appropriately doesn't discuss parameters since there are none, focusing instead on operational prerequisites.

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 specific action ('Start recording') and the target resource ('on the ATEM'), distinguishing it from sibling tools like 'atem_stop_recording' and 'atem_start_streaming'. It provides precise scope by mentioning the required hardware (USB storage) and model capability constraints.

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 states when to use this tool: when USB storage is connected and the ATEM model has recording capability. However, it doesn't provide guidance on when NOT to use it or mention alternatives like 'atem_stop_recording' for stopping an ongoing recording.

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?

Annotations indicate this is a non-destructive, idempotent operation (readOnlyHint: false, destructiveHint: false, idempotentHint: true). The description adds valuable context beyond annotations by specifying prerequisites ('requires streaming to be configured') and hardware constraints ('available on models with streaming capability'), which are not covered by annotations. No contradiction with annotations exists.

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 concise sentences with zero waste: the first states the core action and prerequisite, the second adds hardware constraint. Every sentence earns its place by providing essential context without 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?

Given the tool's complexity (simple action with prerequisites), no output schema, and rich annotations covering safety and idempotency, the description is mostly complete. It adds key context like configuration and hardware requirements. A minor gap is lack of explicit mention of idempotency or potential outcomes, but annotations cover this, making it adequate.

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?

With 0 parameters and 100% schema description coverage, the baseline is 4. The description appropriately adds no parameter details since none exist, focusing instead on prerequisites and constraints, which is sufficient for a parameterless tool.

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 action ('Start streaming') and resource ('on the ATEM'), specifying it's for models with streaming capability. It distinguishes from the sibling 'atem_stop_streaming' by action, though not explicitly named. However, it doesn't fully differentiate from other control tools like 'atem_start_recording' beyond the resource scope.

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 implied usage context by stating it 'requires streaming to be configured in ATEM Software Control' and is 'available on models with streaming capability', which helps determine when it's applicable. However, it lacks explicit guidance on when to use this versus alternatives like 'atem_stop_streaming' or other control tools, and no exclusions are mentioned.

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?

Annotations provide readOnlyHint=false (write operation), destructiveHint=false (safe), and idempotentHint=true (safe to retry). The description adds context about what gets stopped (recording), which is valuable beyond annotations. It doesn't mention side effects like file saving or status changes, but annotations cover the safety profile well.

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 a single, front-loaded sentence with zero waste. Every word earns its place: 'Stop' (action), 'recording' (what), 'on the ATEM' (where). No unnecessary elaboration.

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 0-parameter tool with good annotations (idempotent, non-destructive), the description is reasonably complete. It states the action clearly. Without an output schema, it doesn't explain return values (e.g., success confirmation), but that's acceptable given the tool's simplicity.

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?

With 0 parameters and 100% schema description coverage, the baseline is 4. The description doesn't need to explain parameters since none exist, and it correctly reflects this by not mentioning any inputs.

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 'Stop recording on the ATEM' clearly states the specific action (stop recording) and target resource (ATEM). It distinguishes from siblings like 'atem_start_recording' and 'atem_stop_streaming' by focusing on recording specifically, not streaming or other operations.

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 usage context (when recording is active), but doesn't explicitly state when to use this vs alternatives. It doesn't mention prerequisites like needing 'atem_start_recording' first or exclusions like not working if disconnected. However, the sibling list shows clear alternatives for starting/stopping recording and streaming.

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?

The description adds context beyond annotations: it specifies the action is to stop streaming, which implies it affects an active process. Annotations indicate it's not read-only, not open-world, idempotent, and not destructive, but the description clarifies the operational target (streaming), which is valuable for understanding its behavioral impact in the ATEM system.

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 extremely concise ('Stop streaming on the ATEM.'), consisting of a single, front-loaded sentence that directly states the purpose without any unnecessary words. Every part of the sentence earns its place by specifying the action and target.

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 (0 parameters, no output schema) and rich annotations (covering safety and idempotency), the description is mostly complete. It clearly states what the tool does, but could slightly improve by mentioning idempotency or confirming no parameters are needed, though annotations already cover this.

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 0 parameters with 100% description coverage, so no additional parameter information is needed. The description does not mention parameters, which is appropriate, but it could slightly enhance clarity by noting no parameters are required. Baseline is 4 for 0 parameters, as it adequately handles the lack of parameters.

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 specific action ('Stop streaming') and the target resource ('on the ATEM'), using a precise verb+resource combination. It effectively distinguishes this tool from sibling tools like 'atem_start_streaming' (which initiates streaming) and 'atem_stop_recording' (which stops recording rather than streaming).

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 usage context by specifying 'on the ATEM' and the action 'Stop streaming', suggesting it should be used when streaming is active and needs to be halted. However, it does not explicitly state when not to use it (e.g., if streaming is already stopped) or name alternatives, though the sibling tool 'atem_start_streaming' provides a clear counterpart.

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