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

Annotations already declare non-read-only, non-destructive, non-idempotent, non-open-world, so the safety profile is covered. The description adds genuinely new behavioral context: approval requirements vary by org admin configuration, business workflow approvals always apply, and the anchor must be disclosed in a preview — implying a preview step for a mutation. It does not describe side effects on existing site tasks.

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 core scoping constraint is front-loaded and each sentence adds information. The closing sentence on MCP approval configuration is the least essential but still conveys a real approval gate.

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?

Output schema exists, so return values need no explanation, and the approval and anchorDate guidance covers the main operational risks. Still missing for a write operation: what actually gets created on the site, whether pre-existing tasks are affected, and the identity of the 'id' parameter.

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 0%, so the description must compensate. It does well for data.anchorDate, explaining it is required, how to source it, and that it must be surfaced in the preview. It says nothing about the top-level 'id' or data.siteId beyond the implication that the site is the destination, leaving those two UUIDs unexplained.

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+resource ('Apply a task template') and scopes it to 'an existing site', with an explicit negation of what it does not do (create the destination). It stops short of distinguishing itself from the near-identical sibling apply_project_task_template, and doesn't clarify that 'id' is the template id versus data.siteId being the target site.

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?

Provides a real constraint ('Does not create the destination') and a decision rule for anchorDate (user's requested anchor, else today's local date, disclose in preview). It never names an alternative sibling or states prerequisites such as the template having to exist first, so routing among the several apply_* template tools is left to inference.

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