mcp_opendaw_duplicate_effect

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

With no annotations, the description carries full burden. It discloses that parameter values are copied and that the tool works for both chain types. However, it does not describe side effects (e.g., whether the original is unaffected), where the duplicate is inserted, or behavior on invalid inputs. For a mutation tool, this is insufficient.

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 concise and well-structured: a clear purpose sentence, a reference to the upstream issue, a note on chain support, a bullet-style parameter list, and a return value statement. No superfluous 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?

The description explains the core action, parameters, and return value. However, it omits details on error handling (e.g., invalid indices), placement of the duplicate, and any effects on the original chain. Given the tool's simplicity and the presence of an output schema, it is mostly adequate 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%, but the description explains each parameter with context: unit_index is the AU index, effect_index is the position in the chain, and chain_type specifies audio or MIDI with default. This adds meaning beyond the schema's bare titles and defaults, though it could clarify indexing (0-based?) and range constraints.

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 it duplicates a single effect within an AU's effect chain, copying parameter values. It references the Ctrl+D shortcut and mentions support for both audio and MIDI chains. However, it does not specify where the duplicate is placed (e.g., after the original), which slightly reduces clarity.

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 as the MCP equivalent of Ctrl+D for audio effects and states it works for both chain types. However, it provides no explicit guidance on when to avoid this tool in favor of siblings like clone_effect_chain or duplicate_audiounit, nor does it mention prerequisites or error conditions.

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