Create feedback tunnel

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

Beyond the annotations (readOnly=false, openWorld=true, destructive=false), the description discloses the precise node topology, the built-in seed fallback, and the return payload including node errors. It also notes that fixed resolution prevents feedback runaway, which is useful behavioral context. The description does not explicitly mention any side effects or permissions, but given annotations already set the safety profile, the additional detail is valuable.

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 essential purpose and uses each subsequent sentence to add substantive detail: controls, seed fallback, topology, return value, and sibling differentiation. It is detailed but not redundant, and every sentence contributes to understanding the tool.

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?

Despite having no output schema, the description explicitly lists the return payload (summary, paths, controls, errors, preview image), which is critical for usage. It also covers the input handling, network topology, and the relationship to a sibling tool. Together with the detailed parameter schema and annotations, this is a complete and self-sufficient description.

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 88% schema coverage, the input schema already documents parameter meanings in detail. The description adds only marginal semantic value by mentioning that Zoom, Rotate, HueShift, and Decay are audio-bind-ready and mapping them to the topology (e.g., transformTOP for zoom, levelTOP for decay/hue shift), but it does not explain individual parameter syntax beyond what the schema provides. The baseline of 3 is appropriate.

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 'Build a parameterized infinite-zoom/rotate feedback tunnel,' which clearly states the action (build) and resource (feedback tunnel). It also distinguishes itself from the sibling tool by ending with 'This is the fixed zoom-and-rotate spiral preset; ... use create_feedback_network instead,' explicitly naming the alternative for a different use case.

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 explicit usage guidance by stating this is for the fixed zoom-and-rotate spiral preset and directing users to create_feedback_network for general feedback loops with arbitrary chains of effects. It also implies a use case for live performance with audio-bind-ready controls and a quick-start scenario via the built-in noise seed when no source is provided.

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