list_effects

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

With no annotations to indicate safety or side effects, the description carries the full burden and does so excellently. It discloses confirmed behavioral quirks: category filtering silently misses VST3 effects, add_realtime_effect requires the internal PluginID rather than title, and limit caps results are visible via totalMatched.

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 long but dense with essential caveats and integration details. A small amount of redundancy exists—the category limitation is stated both in the IMPORTANT paragraph and again under the category argument—but the layout is otherwise well-organized and front-loaded.

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 no output schema, no annotations, and four undocumented parameters, the description covers everything an agent needs: parameter behavior, output field meanings, cross-tool usage, failure modes, and filtering strategy. Nothing critical is missing.

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 must fully document the parameters, and it does. Every parameter is explained with type semantics, case-insensitivity, allowed family values, examples, defaults, and the limit's relationship to totalMatched.

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 lists installed effects/plugins across families (Builtin, VST3, Nyquist, etc.), and it distinguishes the result semantics from related effect tools. It also names the exact downstream use of each result field, making the purpose 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 gives excellent practical guidance: use family='VST3' with a search keyword for VSTs, avoid category filtering for third-party plugins, and use title vs. id depending on whether applying effects or adding realtime effects. It does not explicitly state when to prefer an alternative listing tool, but it provides clear context for the intended usage.

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