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

Annotations already declare readOnlyHint, non-destructive and closed-world, so the safety profile is covered and the description only needs to add process behavior. It does add the useful fact that selection is based on which arm actually executed, but it omits the error-when-nothing-ran behavior, which is buried in the fallback parameter text rather than surfaced in the description.

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?

A single sentence with the operation front-loaded and no filler. Every clause carries information about what is consumed (outputs of conditional steps) and what is produced (the first one that ran).

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?

With an output schema present and full schema coverage, the description only needs to convey the control-flow role, which it does succinctly. The one gap is that the empty-fallback error path — arguably the most important failure mode for a pipeline merge node — is disclosed only in the parameter text, not in the 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?

Schema description coverage is 100%, so all four parameters (_files, values, _subject, fallback) are documented in the schema itself, including the warning that an empty fallback turns a no-branch situation into an error. The description adds no parameter-level meaning beyond that, 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?

The description names a concrete operation ('Rejoin two branches') and a concrete result ('emits the first one that actually ran'), which is enough for an agent to identify this as a workflow merge/select node. It does not need to differentiate from a near-identical sibling because none exists in the tool list, but it also never says the emitted value is taken in preference order, which the schema supplies instead.

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?

Usage is implied by 'takes the outputs of several conditional steps' — the agent can infer this belongs after a branch/conditional construct. There is no explicit when-not guidance, no mention of where the fallback should be set, and no comparison to alternatives such as calling a downstream tool directly.

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