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

With no annotations provided, the description carries the full burden. It discloses that the fork has its own id and adminKey, that withSnapshots:true copies snapshots as answer keys, and that TTl causes auto-deletion. However, it doesn't explicitly state the resource is a write operation in a sure way, but 'let the agent mutate the fork freely' implies write access. The description is detailed but leaves out explicit reversibility or permission requirements, which are minor for a copy operation understanding.

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 description is a single block but dense with useful detail. It is front-loaded with the core purpose and then appends usage scenarios. While it is relatively long (over 150 words), every sentence adds relevant context; it's not redundant. The only minor issue is that the grading note could be more condensed, but overall it is well-structured.

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?

Given the tool's complexity (5 parameters, no output schema, no annotations), the description is comprehensive. It covers prerequisites (adminKey for non-demo), side effects (TTL deletion, snapshot copying), and usage patterns (CI runs, demo forking). There is no missing information an agent would need to call it correctly; the absence of an output schema is compensated by the description's mention of 'own id + adminKey'.

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 the baseline is 3. The description adds value beyond the schema by explaining the purpose of ttl ('crashed runs can't leak sandboxes') and withSnapshots ('answer keys travel with it'), and clarifies that adminKey is not needed for 'demo'. However, for parameters like 'name' and 'project', it doesn't add much beyond schema descriptions that already name them unambiguously.

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 starts with 'Copy an entire project — resources + records verbatim, custom routes, behavior settings — into a brand-new project with its own id + adminKey,' clearly stating the verb (copy) and resource (project). This distinguishes it from siblings like create_project (which creates from scratch) and share_project (which shares existing access).

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 description provides explicit when-to-use context: 'Built for parallel eval/CI runs' and specific instructions like 'keep a template project, fork_project per run with a ttl... let the agent mutate the fork freely, then grade with snapshots action:'diff'.' It also includes conditional usage: 'Works on the shared playground with NO adminKey: {"project":"demo"} gives you the demo dataset as your own private project.' This is exemplary usage guidance.

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