Duplicate Excalidraw project

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It does reveal one meaningful trait — the operation only proceeds when the base revision is current, implying an optimistic-concurrency check — but it omits failure behavior on stale revisions, the fact that a new project entity is created, idempotency semantics behind mutationId, and any side effects or return 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?

A single sentence with the verb and key condition front-loaded; every word earns its place and there is no filler. It is efficient, though it leans toward under-specification rather than comfortably concise.

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?

This is a mutating tool with 5 parameters, no annotations, no output schema, and only 40% schema coverage, yet the description offers just one sentence. An agent is left without guidance on the meaning of mutationId and name, the result of a stale-revision attempt, or what the operation returns — far more context is needed for safe invocation.

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 only 40%, covering projectPath and newProjectPath, while baseProjectRevision, mutationId, and name are undocumented in the schema. The description partially compensates by linking 'when its project revision is current' to baseProjectRevision, but it adds nothing about mutationId (presumably an idempotency key) or name (presumably the new duplicate's display name), which the schema also fails to explain.

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 ('Copies') and resource ('a managed project'), and adds the distinguishing condition 'when its project revision is current.' This separates it from siblings like duplicate_canvas (canvas resource) and create_project (creates from scratch rather than copying an existing project). It is clear but does not elaborate on what the copied result contains or how it differs from a fresh create.

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?

No guidance is given on when to use this tool versus create_project or duplicate_canvas, and no alternatives are named. The phrase 'when its project revision is current' implies a precondition the agent must verify (likely via inspect_project), but the description never says how to satisfy it or what to do when the revision is stale.

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