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

Annotations only declare readOnlyHint=false, so the description carries the real burden and does it well: it discloses the confirm-gated two-phase behavior (preview vs execute), the skip rule for coach-edited copies, and idempotency (already-sent items are not re-sent). These are exactly the mutation-safety traits an agent needs before calling a write tool.

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?

Three short sentences, zero filler, with the core effect front-loaded and the safety conditions immediately after. Every clause carries an operational rule.

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 two-parameter mutation tool with no output schema and only a readOnlyHint annotation, it covers the important unknowns: what executes, what is previewed, what is skipped, and what is idempotent. It stops short of stating permission requirements, whether the push can be undone, or how failures are reported.

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 50%: confirm is fully documented in the schema, and the description restates the same gating rule rather than adding to it. programId has no schema description and the description only implies it via 'the program's current items', so meaning added beyond the schema is marginal.

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 action on a specific resource: pushing a program's current items to every enrolled client, with the scope narrowed to copies not hand-edited by the coach. It is clearly distinct from siblings like assign_workout_to_groups or enroll_clients_in_program, though it never names an alternative and 'items' stays slightly generic.

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 concrete inclusion/exclusion rules: clients whose copy the coach edited by hand are skipped, and items already sent are not re-sent. The confirm gate also clarifies that a non-confirmed call is a preview, not a dry-run alternative tool. What is missing is an explicit pointer to a sibling tool for the excluded cases or for enrolling clients.

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