whodb-cli

Official

Overview Schema Source Related Servers Discussions Admin

whodb_platform_project_rename

Destructive

Rename a hosted WhoDB project by id, slug, or name, with optional org targeting. Returns a confirmation token so the rename runs only after user approval.

Instructions

Rename a hosted WhoDB project.

Pass project as id, slug, or name and org when needed for disambiguation. Default mode returns a confirmation token; do not call whodb_platform_confirm until the user approves the rename. Accepts workspace {host, org, project} for per-call targeting without changing defaults.

Input Schema

Name	Required	Description
`org`	No	Organization id, slug, or name. Defaults to the selected organization when available.
`name`	Yes	New project name
`slug`	No	Optional new project slug
`project`	Yes	Project id, slug, or name
`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?

Adds real behavior beyond the annotations: the tool defaults to returning a confirmation token and requires explicit user approval before whodb_platform_confirm, which is critical for a destructiveHint=true operation. It does not disclose side effects of the rename itself (whether the existing slug survives, whether references/bookmarks to the old name break).

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?

Three sentences, each earning its place: the operation first, then target resolution, then the approval gate. No filler and no repetition of schema detail.

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, 5-parameter tool with a nested workspace object, the description covers the operation, targeting, and the confirmation handshake. It stops short of describing post-rename effects (slug handling, downstream reference impact), which matters given destructiveHint=true.

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 the schema already documents every parameter, including the workspace nested object and its host/org/project fields. The description restates that project accepts id, slug, or name and that org disambiguates, adding little beyond what the schema says. Baseline 3 is appropriate here.

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?

Opens with a precise verb+resource: "Rename a hosted WhoDB project." An agent immediately knows the operation and the object. It does not explicitly differentiate from the closest ambiguity in the sibling set (whodb_platform_update or whodb_platform_project_create), so a 4 rather than a 5.

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 a concrete when-not rule naming a sibling: "do not call whodb_platform_confirm until the user approves the rename," and explains the per-call workspace override vs. session defaults. What's missing is any comparison to whodb_platform_update, which an agent might otherwise reach for when changing project metadata.

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

Deploy Server