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

The annotations already declare readOnlyHint=false, openWorldHint=false and destructiveHint=true, but the description adds genuine context the agent would otherwise lack: the template is untouched, due dates are shifted onto the start date, and the new board counts against the free plan's board limit. That quota-consumption detail in particular explains the destructive hint and is real added value.

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 tight sentences with no filler; the core action is front-loaded and each remaining sentence carries distinct content (copy scope, source immutability, quota). Slightly dense but well ordered and appropriately sized for a five-parameter mutation.

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 no output schema, the description should say something about the result (e.g. that it returns the new project or its id), but it does not. It adequately covers the required inputs and the mutation's side effects, leaving the return contract as the notable 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 coverage is 80%, so the baseline is 3, and the description earns a bump by disambiguating the templateKind enum ('starter or saved'), restating the startDate default semantics ('due dates shifted onto the start date, default today'), and clarifying that clientId is optional and constrained to the user's own clients.

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 and resource ('Creates a new project from a starter or saved template') and enumerates exactly what gets copied (lists, labels, tasks with estimates and checklists, settings). It is clear what the tool does, but it never names the adjacent siblings (create_project, create_sample_project, create_task_from_template) to help an agent distinguish this from them without opening schemas.

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?

There is no explicit when-to-use guidance, no when-not-to-use condition, and no alternative sibling named, despite the crowded create_* family. The 'Optionally for one of the user's clients' clause describes a parameter rather than usage context, so the agent must infer selection criteria from context alone.

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