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

Annotations already declare non-read-only, idempotent, non-destructive, closed-world, but the description adds real substance beyond them: an entire snapshot is copied without fresh collection or row charges, 100 free rows remain, schedules start disabled, and reuse of the idempotency key returns the same workspace. The one gap is that 'directory publication authorizes copying linked datasets in the source workspace' is stated without explaining what happens if the source is not published.

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 core action and its destination land in the first sentence, with eligibility, idempotency and return values following in a logical order. It is dense and longer than typical, with a few clauses (e.g. the future run_pipeline estimate flow) that are useful but sit at the tail rather than being essential to invocation.

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?

For a two-required-parameter mutation with an output schema present, the description covers every decision point an agent needs: auth prerequisite, eligibility, idempotent retry behavior, what is and is not copied, and the immediate follow-up tools. Return value internals are handled by the output schema, so nothing material is missing.

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 0%, so the description must carry the load — and it does: dataset_id is clarified as the source dataset's public ID and idempotency_key as a new UUID whose reuse on retry yields the same workspace. It stops short of documenting the 128-char cap on dataset_id or the strict 36-char hex-dash pattern on the key beyond the UUID phrasing.

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?

Opens with a specific verb+resource+destination: copy a public dataset and its runnable collection pipeline into a new free workspace in the connected org. It distinguishes itself from adjacent workspace-lifecycle siblings by explicitly stating no setup, build_workspace or accept_workspace step is needed, so an agent can separate it from accept_workspace/build_workspace 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?

Gives eligibility ('eligible public dataset'), a prerequisite ('requires authenticated organisation access'), explicit exclusions ('saved site logins are unsupported') and named alternatives that are not needed. It also tells the agent exactly when to retry (reuse dataset_id and idempotency_key) and what downstream tools follow (query_dataset, browse_dataset_rows, export_dataset).

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