Run up to 20 typed vMix actions in order to control previews, transitions, overlays, text/images, playback/audio, layers, stinger bindings, and replay.
Run up to 20 typed actions in order. Supports preview, transition, overlay, text/image, playback/audio, layers, native transition buttons, GT stinger binding and replay. No arbitrary API function.
| Name | Required | Description | Default |
|---|---|---|---|
| actions | Yes | ||
| dry_run | No | ||
| request_id | Yes |
Changes observed during successful MCP inspections.
v0.1.0Does 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.