whodb-cli

Official

Overview Schema Source Related Servers Discussions Admin

whodb_platform_project_create

Destructive

Create a hosted WhoDB project in an organization and return a confirmation token, so the user can approve the project before it is provisioned.

Instructions

Create a hosted WhoDB project in an organization.

Pass org when the selected organization is not the intended target. Default mode returns a confirmation token; do not call whodb_platform_confirm until the user approves the project creation. 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	Project 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.
`description`	No	Project description

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 declare destructive, non-idempotent, open-world, non-read-only, so the safety profile is covered. The description adds genuinely new behavior: default mode returns a confirmation token and confirmation must wait for user approval, plus that workspace targeting does not mutate defaults. It does not state whether creation is reversible or what the token payload looks like, but the output schema may carry that.

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

Conciseness4/5

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

Four sentences, front-loaded with purpose and the confirmation workflow; nothing is filler. Some phrasing (workspace targeting) restates the workspace schema description, costing a little density.

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?

A destructive, non-idempotent mutation with nested workspace object and a confirmation gate is adequately explained: targeting precedence, approval gating, and default preservation are all present. With an output schema and full parameter coverage, the remaining gaps (reversibility, rate limits) are minor.

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

Parameters4/5

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

Schema coverage is 100%, so baseline is 3. The description still adds intent-level meaning the schema lacks: org should only be passed when it differs from the selected organization, and workspace is per-call only and leaves defaults unchanged.

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 and resource ("Create a hosted WhoDB project in an organization") that clearly distinguishes it from project_delete, project_rename, and project_access siblings. It never names an alternative tool explicitly, so an agent must infer the boundary against the generic whodb_platform_create.

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 selection rules for the org parameter ("Pass org when the selected organization is not the intended target") and a strict do-not-call-until-approved rule for whodb_platform_confirm. There is no guidance on when to prefer this over sibling creation tools, but the in-scope conditional behavior is well covered.

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

Deploy Server