whodb-cli

Official

Overview Schema Source Related Servers Discussions Admin

whodb_platform_clone

Destructive

Clones a hosted dataset, ontology, transform, or function in a selected project and returns a confirmation token for previewing the change before you approve it.

Instructions

Clone a hosted dataset, ontology, transform, or function in the selected project.

Default mode returns a confirmation token; do not call whodb_platform_confirm until the user approves the preview. Accepts workspace {host, org, project} for per-call targeting without changing defaults.

Input Schema

Name	Required	Description
`source`	Yes	Source resource id, name, or api name
`new_name`	Yes	New resource name or ontology api name/display name
`resource`	Yes	Resource to clone: dataset, ontology, transform, or function
`workspace`	No	Optional target for this call only. Omit to use the session default set by whodb_platform_session_use, then process/saved defaults. Discover targets with whodb_platform_hosts, whodb_platform_orgs and whodb_platform_projects.

Output Schema

Name	Required	Description
`error`	No
`scope`	No
`status`	No
`warning`	No
`commands`	No
`recovery`	No
`retryable`	No
`workspace`	No	Optional target for this call only. Omit to use the session default set by whodb_platform_session_use, then process/saved defaults. Discover targets with whodb_platform_hosts, whodb_platform_orgs and whodb_platform_projects.
`error_code`	No
`next_steps`	No
`request_id`	No
`result_json`	No
`setup_status`	No
`suggested_tools`	No
`confirmation_token`	No
`confirmation_action`	No
`confirmation_expiry`	No
`confirmation_preview`	No
`idempotency_replayed`	No
`confirmation_required`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedv0.136.0Oct 23, 2026
- changedOutput schema / properties / recovery / type
```
Previous value: -[
-  "null",
-  "object"
-]New value: +"object"
```
- changedOutput schema / properties / suggested_tools / type
```
Previous value: -[
-  "null",
-  "array"
-]New value: +"array"
```
Addedv0.135.0Oct 15, 2026

TDQS

A4/5.0

Behavior4/5

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

Annotations already flag destructiveHint=true, idempotentHint=false and openWorldHint=true; the description adds the crucial two-step preview/confirm gating, which materially changes how an agent should behave. It also clarifies that the workspace parameter is scoped to a single call. It does not say what the clone copies (permissions, versions, dependents) or how name collisions are handled.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, no filler: the capability and scope come first, then the confirm-gating rule and the workspace-targeting caveat. Every clause conveys actionable information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a destructive, non-idempotent mutation with a nested workspace object, the description covers the safety workflow and per-call targeting, and an output schema exists so return values need no explanation. What remains unstated is which artifacts come along with a clone and any preconditions on the source resource.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so resource, source, new_name and the nested workspace object are all documented in the schema itself. The description's note that workspace accepts {host, org, project} without altering defaults largely restates the schema's 'Optional target for this call only' wording, so it adds only marginal value. Baseline 3 applies when the schema carries the semantics.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb (clone) and enumerates the exact resource types it operates on (dataset, ontology, transform, function) within the selected project. This implicitly separates it from the create/update/delete siblings, though it never names an alternative such as whodb_platform_create_dataset or whodb_platform_create to draw the boundary explicitly.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives concrete workflow guidance: the default call returns a confirmation token and whodb_platform_confirm must not be invoked until the user approves the preview. It also explains that workspace targeting is per-call and does not change defaults. No guidance is offered on when to clone versus create a fresh resource, which would complete the picture.

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

Deploy Server