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

Annotations cover safety flags (write, not idempotent, not destructive), and the description adds real context beyond them: what is copied (project + script), what is excluded (responses), and the resulting state (new project is inactive until opened). It stops short of noting that repeated calls produce distinct projects, but the annotations already flag non-idempotency.

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, front-loaded with the core action, then the two most decision-relevant qualifications (responses excluded, project inactive). No filler sentences.

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 adequately conveys the resulting artifact and its inactive state for a two-parameter clone operation. The main gap is the undocumented optional name argument and what the new project's identity looks like.

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%: project_id carries a description while the optional 'name' parameter has none. The tool description says nothing about parameters at all, so it fails to compensate for the undocumented name argument (e.g., that omitting it reuses/defaults the source name).

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 ('Copy a project and its script into a new inactive project') and clarifies scope by noting responses are not copied, which separates it from clone_template (templates) in practice. It never names a sibling explicitly, so differentiation relies on inference from the resource named.

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 copy reaches nobody until you open it' implies the clone-then-open workflow and hints at open_project as the follow-up, but there is no explicit when-to-use statement, no reference to alternatives like create_project, and no prerequisites named.

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