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

Annotations only cover mutability/open-world; the description adds substantial behavior: multi-agent turn-taking without a human in the loop, results landing in the room stream, that any room member can read or stop it, and a needs_confirmation envelope requiring an explicit approval wait before proceeding. These are concrete operational facts 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?

Front-loaded with the core action, then usage, then the approval caveat. Each sentence carries content, though the first sentence is long and dense with clauses (zv1 + flows + sidebar + turn-taking + stream return).

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 complex 10-parameter mutation tool with no output schema, the description covers the mechanism, prerequisite, side effect (result to room stream), and the confirmation/approval path an agent must handle. Only the format of a successful return (beyond the stream) is left implicit, a minor gap.

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 100%, so all ten parameters (including the mode enum, maxTurns, sidebarId, approvalId, workspace) are already documented. The description restates the flowIds precondition and the goal/approval intent but adds no syntax or format detail beyond the schema, so the baseline 3 applies.

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 ('Starts') and the exact resources involved ('zv1 and flows in a room working on something together in a sidebar'), plus how they operate (take turns, result returns to the room stream). It also names the prerequisite sibling rooms_add_flow, so it is clearly distinguishable from workbench_flows_run and rooms_post.

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?

Gives an explicit trigger ('Use it when someone asks for agents to work something out, or to hand a specialist flow a job') and cites the rooms_add_flow prerequisite. It does not contrast against the closest alternative of running a single flow directly (workbench_flows_run), which is the main remaining gap.

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