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

Annotations already declare a non-read-only, non-destructive, non-idempotent, closed-world operation, and the description adds real value on top: it discloses that a new project id is produced (consistent with idempotentHint=false) and that the operation consumes no credits, which is billing behavior no annotation covers. It leaves unclear what is not copied (visibility, publish schedule) and whether the call is synchronous.

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?

A single compact sentence that front-loads the action, then the fidelity of the copy, then the cost guarantee. Nothing is redundant or padded.

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 four annotations, full schema coverage, and an output schema covering the return, the description is nearly sufficient: it explains scope of duplication and the credit cost. The main remaining gap is the absence of any note about what is excluded from the copy or whether the operation is asynchronous.

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 100%, so both pid and name (including the default naming convention) are fully documented in the schema. The description adds nothing about parameters beyond the implicit notion of a new project id, which meets the baseline for well-covered schemas.

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 specific verb and resource ("Duplicate an existing Revid project") and immediately clarifies the semantics: same content and folder, new project id. That distinguishes it clearly from siblings like rename_project, edit_project, delete_project, and create_episode without needing to open 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?

"Uses no credits" is a genuine decision cue that implies an agent should duplicate rather than rebuild a project, but the description never states when not to use it, nor names an alternative tool or any prerequisite (e.g., that the source project must exist or be accessible).

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