whodb-cli

Official

Overview Schema Source Related Servers Discussions Admin

whodb_platform_source_delete

Destructive

Initiates deletion of a hosted WhoDB source by returning a confirmation token; nothing is removed until the token is approved.

Instructions

Prepare deletion of a hosted WhoDB source.

This deletes nothing until the returned confirmation token is approved with whodb_platform_confirm. Use whodb_platform_sources first to verify the target source. This is destructive. Explain the deletion target and do not call whodb_platform_confirm until the user approves the confirmation preview. Accepts workspace {host, org, project} for per-call targeting without changing defaults.

Input Schema

Name	Required	Description	Default
`source`	Yes	Hosted source id 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
`source`	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
`setup_status`	No
`suggested_tools`	No
`confirmation_token`	No
`confirmation_action`	No
`confirmation_expiry`	No
`confirmation_preview`	No
`confirmation_required`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed4 schema fields changedv0.136.0Oct 23, 2026

addedOutput schema / properties / error_code
```
Added value: +{
+  "type": "string"
+}
```

addedOutput schema / properties / recovery

Added value: +{
+  "additionalProperties": false,
+  "properties": {
+    "LikelyCause": {
+      "type": "string"
+    },
+    "NextSteps": {
+      "items": {
+        "type": "string"
+      },
+      "type": [
+        "null",
+        "array"
+      ]
+    }
+  },
+  "required": [
+    "LikelyCause",
+    "NextSteps"
+  ],
+  "type": "object"
+}

addedOutput schema / properties / retryable
```
Added value: +{
+  "type": "boolean"
+}
```

addedOutput schema / properties / suggested_tools

Added value: +{
+  "items": {
+    "type": "string"
+  },
+  "type": "array"
+}

Addedv0.135.0Oct 15, 2026

TDQS

A4.4/5.0

Behavior4/5

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

Annotations already declare destructiveHint=true, idempotentHint=false, readOnlyHint=false, so the safety profile is largely covered. The description still adds high-value behavior the annotations cannot express: the two-phase token flow, that nothing is deleted at this call, and the agent's obligation to explain the target and obtain user approval. It does not describe the confirmation payload's content or expiry.

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?

Front-loaded with the key fact (prepare, not delete), then the confirm dependency, then the safety instruction. Slightly wasteful that the final sentence paraphrases the workspace schema, but every other sentence carries distinct weight.

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

Completeness5/5

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

For a destructive two-phase operation with an output schema (confirmation token/preview) and rich annotations, the description supplies everything an agent needs: preconditions, ordering with siblings, the approval gate, and the mutation's true effect. Nothing material is missing.

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 'source' and the nested workspace fields, including that workspace is per-call only. The description's workspace sentence mostly restates the schema; only 'verify the target source' hints at resolution semantics (id vs. name). Baseline 3 is appropriate.

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

Purpose5/5

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

States a specific verb+object ('Prepare deletion of a hosted WhoDB source') and, crucially, that this is a prepare-only step that deletes nothing until a confirmation token is approved. The resource scope ('hosted source') plus the token workflow make it distinguishable from the sibling delete tools.

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

Usage Guidelines5/5

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

Explicit when-to-use chain: run whodb_platform_sources first to verify the target, then this tool, then whodb_platform_confirm only after user approval. It also states an exclusion ('do not call whodb_platform_confirm until the user approves the confirmation preview'), leaving nothing to inference.

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

Deploy Server