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

Annotations only declare write/open-world/safe-mutation; the description adds substantive behavior beyond them: workouts appear on the calendar immediately, they can be edited per client afterwards, each call is confirmed by default, and it reaches other people so user confirmation is required. Auth requirements (Cotlet API key with app access) are also disclosed. No rate limits or failure modes are mentioned, so not a 5.

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 and reasonably short, but the first two sentences say nearly the same thing twice ("Add a program to a client's training calendar from a start date" / "Adds a program from your Program Library to one client's training calendar, starting on the date you give"), which costs space without adding information.

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 mutation tool with no output schema, the description covers the important agent-facing facts: side effects on the client calendar, post-hoc editability, confirmation behavior, cross-user impact, and auth. Nothing critical is missing, though it could note whether re-assignment duplicates or replaces existing calendar entries.

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 100%, so the baseline is 3, but the description adds genuine semantics the schema lacks: start_day and end_day together control partial-program assignment, and the defaults implied for the full program. It also reinforces the origin of client_id/program_id (list_clients, list_programs), which the schema already states.

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 states a concrete verb and resource: adding a program from the Program Library onto one client's training calendar starting at a given date. The scope (one client, from a start date, partial assignment via start_day/end_day) makes it clearly distinguishable from everfit_assign_task and everfit_add_client_to_autoflow without opening any schema.

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?

It gives real usage context: use start_day/end_day to assign only part of the program, workouts are adjustable afterwards, and confirmation is on by default and can be turned off. It does not name an alternative tool or state when not to use it, so it stops short of explicit routing guidance.

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