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

Annotations already establish destructiveHint=true and readOnlyHint=false, and the description adds useful traits beyond that: ordered execution, a 20-action ceiling, and the 'no arbitrary API' restriction. It does not disclose failure behavior, partial application if an action fails, or whether dry_run prevents side effects.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two dense sentences with the core constraint front-loaded: 'Run up to 20 typed actions in order.' The capability list is compact and the negative constraint 'No arbitrary API function' 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 tool with 12 action variants and no output schema, a high-level category list plus 'no arbitrary API' is not complete guidance. Missing dry_run semantics, error/partial-execution behavior, and any contrast with sibling single-action tools leave real gaps for an agent deciding how to invoke it.

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% schema-description coverage, the description needed to explain request_id and dry_run, but it never mentions them. The action-type list names categories that map to the array schema but adds no detail on fields like effect, duration_ms, or rectangle, leaving the schema to do all the 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 first sentence names a concrete verb and resource: 'Run up to 20 typed actions in order.' The capability list makes the tool's domain unmistakable, and 'No arbitrary API function' explicitly separates it from generic operation/execution siblings. This is a clear, specific purpose statement.

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 the tool is for batch execution of the listed typed action categories and explicitly rules out arbitrary API calls. However, it never says when to prefer vmix_actions over vmix_transition or vmix_trigger_arm, nor does it mention the dry_run workflow or any prerequisites.

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 meaningful behavioral detail beyond the annotations: it discloses SHA-256-based filename generation, the configurable asset root via VMIX_VISIBLE_ASSET_ROOT, and the important boundary that no vMix import occurs. The destructiveHint is consistent with writing/copying into a directory, so there is no 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 two tight sentences with no filler. The core operation is front-loaded, and the environment-variable note and non-import clarification each add distinct 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?

For a low-complexity tool with only one required parameter and no output schema, the description provides enough operational context: copy behavior, naming scheme, configurable root, and a clear non-goal. It does not explain dry_run, but that is a minor gap 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?

Schema description coverage is 0%, and the description does not mention source_path or dry_run at all. The phrase 'Copy a local media file' loosely implies source_path, but dry_run is left entirely to inference, and the description fails to compensate for the lack of schema 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 opens with a specific verb and resource: 'Copy a local media file into the configured asset directory.' It also distinguishes the tool from siblings by explicitly stating it does not import into vMix, so an agent can identify what this tool is and is not 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 gives clear contextual guidance by stating the tool stages assets into a configured directory and explicitly warns 'Does not import into vMix.' This implicitly tells the agent to use this tool when preparing media files for later vMix use rather than for immediate import, though it does not name a specific alternative tool.

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 annotations already declare readOnlyHint=true and destructiveHint=false, and the word 'List' matches that safety profile. The description adds useful scope by noting that triggers are 'MCP-managed' and that armed state is included, going slightly 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?

A single sentence with the verb and objects front-loaded, containing no filler or redundant restatement of the tool name. Every element adds information: what is listed and what detail is included.

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, read-only list tool with no output schema, the description is complete enough. It states exactly what is returned and highlights the armed-state field, and the sibling set covers the related mutation operations.

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 takes zero parameters, so the parameter schema is empty and schema coverage is effectively complete. There is no additional parameter burden for the description to carry, earning the baseline 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 starts with 'List' and names two concrete resources: 'saved transition presets' and 'MCP-managed triggers', plus the 'armed state' detail. This is far more specific than the tool name alone and sets it apart from write-oriented siblings like vmix_transition_preset_save and vmix_trigger_arm.

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 use case is clear: call this when you need an overview of saved presets and MCP-managed triggers and their armed state. It does not explicitly name alternatives or state when not to use it, but for a zero-parameter read-only list that is a minor omission.

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?

Discloses key behaviors beyond annotations: returns a GUID, does not take input on air, and references existing files rather than copying bytes. Annotations only indicate write/destructive nature; the description adds context about side effects and return 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?

Three concise sentences: purpose, usage guidance, and side-effect caveat. Front-loaded with the main action, no filler.

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?

Covers purpose, return value, and a key usage rule, but lacks parameter-level explanations given zero schema descriptions. Also does not mention error conditions or the dry_run flag. Adequate for a simple tool but incomplete for full comprehension.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate for parameter meaning. It only hints at 'type' for input types and 'value' for content, but does not explain name, request_id, or dry_run. The schema provides no descriptions, leaving parameters largely unexplained.

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: import an existing file or create a colour input, and returns a GUID. It differentiates from asset_stage by explicitly stating when to use that tool, and notes it does not put input on air, giving a distinct 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?

Explicitly tells the agent when to use this tool versus asset_stage: 'Use asset_stage first when bytes need copying.' It also implies when to use this (when the file is already visible to vMix), providing clear 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 already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds useful context by saying 'real' state is read, implying live system data, but it does not disclose additional behavior such as failure modes, connection requirements, or output shape.

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?

One compact sentence that leads with the action verb and then lists the concrete items read. There is no filler, repetition, or unnecessary context.

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, read-only inspection tool, the description reasonably captures what data will be returned by enumerating vMix state categories. Minor gaps remain around error/connection behavior, but the low complexity and annotation coverage make the description sufficiently 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?

The input schema has zero parameters, so parameter-level documentation is unnecessary. Per rubric guidance, 0 params receives a baseline of 4; no additional parameter semantics are needed.

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 uses a specific verb ('Read') and names concrete resources: vMix inputs, GUIDs, title fields, layers, program, preview, and overlays. It clearly communicates a read-only inspection tool, though it does not explicitly differentiate itself from similar sibling tools like vmix_operation_get.

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 wording 'Read real vMix inputs' implies the tool is for inspecting live vMix state rather than modifying or configuring it. However, it provides no explicit when-to-use guidance, exclusions, or mention of alternative 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 already declare readOnlyHint=true and destructiveHint=false. The description adds useful behavioral context by explicitly warning that the tool produces setup steps only and does not modify vMix, which clarifies the unsupported, non-applied nature of the output.

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 the core purpose front-loaded. The read-only warning follows immediately and every sentence adds necessary information without waste.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

This tool has a complex input schema with 7 parameters and multiple action variants, no output schema, and 0% parameter coverage. The description is a high-level summary and does not explain what the generated setup steps look like, how they should be used, or how to choose among the many possible actions. It is not complete enough for confident invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description needed to compensate. It only hints at the 'kind' parameter via 'trigger or non-GT Stinger' and says nothing about 'input,' 'actions,' 'slot,' 'event,' 'duration_ms,' or 'cut_point_ms.' An agent still lacks semantic guidance for most 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 states a specific verb and resource: 'Produce concrete native vMix setup steps' for 'a trigger or non-GT Stinger.' This is clear about the tool's purpose, though it does not explicitly distinguish it from sibling tools like vmix_transition_configure or vmix_trigger_save.

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 by stating this tool is read-only and that 'these unsupported settings are NOT written into vMix.' This implies when to use it versus actually applying vMix changes, though it does not name specific alternative 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 already indicate a safe read-only operation, and the description adds meaningful behavioral context: the same request_id is never executed twice and this guarantee persists across restarts. This goes beyond the schema and annotations without contradicting them.

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 concise sentences, front-loaded with the core action and followed by an important behavioral guarantee. There is no redundant or filler content; 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 simple one-parameter read-only lookup, the description covers the core purpose, persistence, and idempotency guarantee. It does not describe the response format or error behavior, but given the annotations and minimal schema, the remaining gaps are minor.

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 description mentions request_id in a meaningful way, indicating that it identifies an operation and carries idempotency semantics. However, with schema coverage at 0%, it does not fully compensate by explaining the source of the request_id, its exact purpose, or how it maps to an operation beyond the name and pattern.

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 states a specific verb and resource: 'Get persisted operation status.' It clearly identifies what the tool retrieves and distinguishes it from sibling mutation or configuration tools. The term 'persisted' adds a meaningful scope that separates it from a transient/live status check.

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 the tool should be used when retrieving the status of a previously submitted operation, which is clear from 'Get persisted operation status.' However, it provides no explicit guidance about when not to use it, nor does it name alternatives or explain how it relates to sibling tools that may produce or consume request IDs.

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 details beyond the annotations: 'Never removes inputs on failure' provides a safety guarantee that is not implied by destructiveHint=true, and 'Pixel coordinates are based on the vMix preset resolution' clarifies a technical aspect of the input coordinates. This goes beyond what annotations convey, though it does not describe the full mutation effect on the vMix state.

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 long, with the primary purpose front-loaded and no redundant filler. Every clause adds information: the scene type, the layer capacity, the geometry options, and the coordinate system. It is an excellent model of brevity.

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 five parameters and a nested array schema, the description gives enough context to understand the core function but omits key operational details like the role of dry_run and request_id. The absence of an output schema and lack of parameter explanations mean an agent may need to guess at some aspects, so it is only moderately 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 schema description coverage at 0%, the description must compensate by explaining parameters. It does mention 'layers', 'pixel rectangles and crop', and hints at the background via 'colour-backed', but it does not explain 'dry_run', 'request_id', or the exact structure of the layers array beyond the schema. Several parameters remain undocumented in plain language, so the description only partially compensates.

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 ('Build') and the resource ('off-air colour-backed scene') with specifics like 'up to 10 layers, pixel rectangles and crop'. It is unambiguous about what the tool does. However, it does not explicitly differentiate from sibling tools like vmix_scene_template, so it earns a 4 rather than a 5.

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 gives no explicit guidance on when to use this tool versus alternatives. It implies it is for off-air scenes (via the phrase 'off-air'), but it does not state exclusions or recommend sibling tools for other scenarios. This leaves 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?

The annotation already flags destructiveHint, and the description adds the useful constraints that sources must pre-exist and that output resolution is unchanged. It does not disclose post-conditions, such as whether existing scenes are overwritten or what error behavior looks like, but the annotations keep the baseline low enough that this is acceptable.

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 tight sentences that front-load the action and then state prerequisites and constraints. No filler words; every clause adds 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?

The core behavior (building scene layouts) and prerequisites are covered, and there's no output schema to explain. However, the dry_run parameter and the exact difference from vmix_scene_create are not addressed, leaving an otherwise decent description slightly incomplete for a 7-parameter 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?

With 0% schema description coverage, the description must compensate. It does add meaning for layout (lists the valid values), sources ('must already exist'), and width/height ('must match preset'), but it leaves name, request_id, and dry_run semantically unexplained. It partially compensates but does not cover all 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 'Build' and the resource 'scene', with layout variants enumerated. It does not explicitly differentiate from sibling vmix_scene_create, but the layout list makes the tool's scope reasonably distinct.

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 two useful conditions — 'Sources must already exist' and 'Canvas dimensions must match your vMix preset' — which give the agent a sense of when it is appropriate. However, it does not compare against alternatives such as vmix_scene_create, nor does it state when not to use this tool.

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 declare destructiveHint=true and readOnlyHint=false, and the description adds useful behavioral detail beyond that: all fields validate before writing, and multiple updates are ordered but not frame-atomic. This gives the agent meaningful expectations about failure modes and transactionality. It doesn't discuss auth or exact failure behavior, but the added context is valuable given the destructive annotation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three sentences, each earning its place: what it does, how to prepare (inspect field names), and behavioral warnings. Front-loaded with the primary action and purpose. No fluff or repetition of schema content.

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 destructive, multi-update tool with no output schema, the description covers key concerns: field name inspection, validation-before-write, and non-atomic ordering. It doesn't explain the return value or what happens when validation fails, but the prerequisites and transactional behavior are addressed. Given the tool's complexity and the destructive annotation, this is nearly complete but not fully comprehensive.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate, and it does partially: it explains the meaning of 'fields' as named text fields on a title input and hints that values are strings. It also mentions 'dry_run' exists by saying 'All fields validate before writing,' but it does not explicitly document request_id, dry_run behavior, or the format of field names. The description adds some semantic meaning beyond the raw schema but doesn't fully cover all four 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 states a specific verb and resource ('Update named text fields on a title input') and clearly distinguishes it from inspection tools by warning to inspect exact field names first. It doesn't explicitly name a sibling alternative, but the behavior is specific enough that an agent can tell it apart from vmix_inspect and other sibling tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives implicit but clear usage context: inspect field names before updating, since GT uses .Text. It doesn't explicitly mention when not to use the tool or name alternatives, but the inspection prerequisite is a useful usage guideline. No explicit exclusion of alternatives is provided, so not a perfect 5.

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 aligns with the destructiveHint annotation by indicating a state-changing transition, rather than a read-only operation. However, it does not disclose the specific effects of the transition, reversibility, failure behavior, or why the destructive hint is present, so it adds limited behavioral context 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 sentence with no filler or redundant restatement of the tool name. The key operation is front-loaded and the return behavior is included compactly.

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 destructive action with four parameters and no output schema, the description is too sparse. It omits dry_run semantics, request_id purpose, any safety caveats, and any guidance on how this tool relates to vmix_transition_configure or vmix_transition_preset_save, leaving an agent without enough context to call it confidently.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate for parameter meaning. It loosely maps 'specified input' to the input parameter and 'saved MCP transition preset' to preset, but it does not explain dry_run or request_id, both of which are important for safe and correct invocation.

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 states a specific action: taking a specified input on the main program using a saved transition preset, and notes it returns state confirmation. It clearly identifies the operation and resource, though it does not explicitly differentiate itself from sibling tools like vmix_transition_configure or vmix_transition_preset_save.

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 the tool should be used when a saved MCP transition preset is available, but it gives no explicit when-to-use guidance, no exclusions, and no mention of alternatives. There is also no guidance about dry_run or conditions under which the transition should not be performed.

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 mark this as a non-read-only, destructive operation; the description's 'Native writes via documented API' confirms that and adds that writes go through vMix's documented API rather than an unofficial mechanism. It does not disclose that reconfiguring a button overwrites its prior effect/duration, but it does not contradict 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?

Three short sentences with no filler: core function, optional capability, and write mechanism each earn their place, with the primary purpose front-loaded. Every sentence adds distinct 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?

For a 7-parameter destructive write with no output schema and zero schema descriptions, the description covers the primary action and the optional binding but omits dry_run semantics, whether gt_input and stinger_slot must be provided together, and any error or return behavior. Adequate for basic invocation but with clear 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 0%, so the description must compensate. It maps the core domain parameters — button ('four native buttons'), effect, duration_ms ('duration'), gt_input ('GT title input'), and stinger_slot ('Stinger slot') — but leaves request_id and especially dry_run, a behavior-changing boolean, unexplained.

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?

States a specific verb and resource ('Configure one of the four native vMix transition buttons') and enumerates exactly what is configured: effect, duration, and optionally binding a GT title input to a Stinger slot. This clearly differentiates it from siblings like vmix_transition and vmix_transition_preset_save, which concern performing or saving transitions rather than configuring the native buttons.

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 use case is implied — configure a native transition button or bind a GT title to a Stinger slot — but no explicit when-to-use or when-not-to-use guidance is given, and no alternatives are named. An agent must infer how this differs from siblings such as vmix_transition_preset_save or vmix_trigger_save.

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 flag destructiveHint=true and readOnlyHint=false, but the description adds no behavioral context beyond the word 'save' – it does not mention overwriting an existing preset, the semantics of dry_run, or side effects. With a destructive write, an agent would benefit from explicit overwrite behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences with no filler; the purpose is front-loaded and the alternative is stated second. Every phrase 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?

The tool is simple enough that the core action is clear, and the schema provides all parameter constraints. However, no output schema exists, and the description omits overwrite/dry_run semantics, which matter for a destructive save 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 0%, and the description does not describe any parameter, including the non-obvious dry_run flag, the meaning of effect values, or the name pattern. The schema property names are somewhat self-explanatory, but the description itself compensates for the low schema coverage only by hinting at the overall purpose.

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?

States a specific verb ('Save') and resource ('reusable MCP transition preset'), and explicitly contrasts with transition_configure, which targets native vMix buttons. An agent can immediately distinguish the tool's role from its closest sibling.

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?

Names an alternative, transition_configure, and gives a condition for choosing it rather than this tool. It does not enumerate when-not-to-use conditions for other siblings, such as vmix_transition for applying transitions, but the core use case is clear from the first sentence.

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?

Beyond the annotations (destructiveHint=true, readOnlyHint=false), the description reveals important behavior: no startup/reconnect catch-up, persistence across restarts being disarmed, and cancellation of pending delayed actions on disarm. These are non-obvious side effects that materially affect how an agent reasons about the call.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three compact sentences with no filler; the purpose is front-loaded and the behavioral caveats are compressed. Every sentence adds information the agent needs.

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 two-parameter stateful toggle with annotations already covering safety, the description covers the core purpose, the restart behavior, and the key side effect of disarming. Nothing critical is missing for an agent to invoke the tool correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, so the description bears the burden of explaining parameters. It implies that 'id' refers to a saved managed trigger and that 'armed' maps to the arm/disarm verb, and it adds a meaningful effect of armed=false. However, it never explicitly defines the id format, source, or full semantics of the boolean, leaving a partial gap.

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 uses a specific verb pair ('arm/disarm') and a precise resource ('saved managed trigger'), making the operation distinct from the sibling trigger_save and trigger_delete tools. It clearly conveys that this tool toggles state on an existing trigger rather than creating or destroying one.

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 gives clear context for when this tool matters: restarting MCP disarms all triggers, so an agent knows to call this to re-arm them. It does not explicitly name alternatives or state when not to use it, so it stops short of a 5.

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 reinforces the destructive nature of the operation ('disarm and remove') which aligns with the destructiveHint annotation, but it adds no additional behavioral context beyond that, such as irreversibility, side effects, or permission requirements. The phrase 'MCP-managed' hints at scope but doesn't elaborate.

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, concise sentence with no wasted words. It front-loads the action ('disarm and remove') and the resource. While brief, it conveys the core purpose effectively, though it could benefit from additional 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?

For a destructive operation with one parameter and no output schema, the description is incomplete. It fails to explain the parameter, any prerequisites (e.g., that the trigger must be MCP-managed), or consequences of the action. The agent is left with insufficient information to safely invoke the 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 description does not explain the 'id' parameter at all. With a schema coverage of 0%, the description should compensate by indicating that 'id' refers to the trigger identifier, but it is omitted entirely, leaving the agent without the necessary context to supply a correct 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 tool disarms and removes an MCP-managed trigger definition. The verb 'disarm and remove' is specific, and the resource is 'MCP-managed trigger definition', which distinguishes it from siblings like vmix_trigger_save and vmix_trigger_arm.

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 vmix_trigger_save or vmix_trigger_arm. There is no mention of prerequisites, conditions, or exclusions, leaving the agent to infer the usage context from the name.

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 flag this as non-read-only and destructive, and the description adds meaningful behavioral context: events are polled state changes, playback_stopped includes manual pauses, playback_time can detect seeks, and the default is one-shot per arm. This goes beyond the annotations, though it does not detail save-related side effects such as overwrite semantics.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three sentences, no wasted words. The core purpose is front-loaded, and the behavioral clarifications are packed into the remaining sentences 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?

The description is helpful for event selection and the disarmed state, and the schema covers structure well. Still, with no output schema, the description does not state what a successful save returns, whether saving an existing id overwrites it, or how the saved trigger is later armed. These are meaningful gaps for a complex, destructive mutation 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?

With 0% schema description coverage, the description partially compensates by clarifying event semantics and the default one-shot behavior, which maps to max_fires. However, it does not explain the dry_run parameter or how the trigger object's lifecycle relates to saving, leaving a gap despite the rich 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 names a specific verb ('Save'), a resource ('MCP-managed trigger'), and a clear state ('DISARMED'). It also distinguishes this tool from siblings like vmix_trigger_arm and vmix_trigger_delete, and clarifies that this is not a native vMix trigger.

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 phrase 'Save a DISARMED MCP-managed trigger' implies the intended workflow of persisting before arming, and 'Default one-shot per arm' hints at lifecycle. However, it never explicitly says when to use this tool versus vmix_trigger_arm or vmix_trigger_delete, leaving the routing to inference.

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