whodb-cli

Official

Overview Schema Source Related Servers Discussions Admin

whodb_platform_source_config

Read-onlyIdempotent

Retrieve a hosted WhoDB source's connection configuration with passwords, tokens, and keys masked, so you can inspect source shape without exposing credentials.

Instructions

Return redacted connection configuration for one hosted WhoDB source.

Secrets such as passwords, tokens, client secrets, and private keys are masked. Use this to understand source shape without exposing credentials. 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
`config`	Yes
`source`	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

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.1/5.0

Behavior4/5

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

Annotations already declare readOnly/idempotent/openWorld, so the bar is lower, but the description adds real value: it names exactly what is masked (passwords, tokens, client secrets, private keys) and explains that the workspace argument is per-call and does not change defaults. It stops short of describing response shape or whether masked values appear as placeholders.

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?

Four short sentences, front-loaded with the resource and the credential-safety guarantee, then the targeting escape hatch. Nothing is redundant or padded.

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?

An output schema exists, so return values need not be described; annotations cover the safety profile; schema covers both parameters fully. The description supplies the one thing structured fields cannot: that secrets are masked, which is the core behavioral fact an agent needs.

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 coverage is 100% and already documents source as id-or-name and the full workspace {host, org, project} semantics including session-default fallback. The description largely restates the workspace per-call behavior rather than adding new syntax or resolution rules, so baseline 3 applies.

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 ('Return redacted connection configuration for one hosted WhoDB source') and adds a scope qualifier ('redacted', 'one source') that distinguishes it from bulk listing siblings like whodb_platform_sources. It does not explicitly contrast with the closest read siblings (whodb_platform_source_fields, whodb_platform_source_test, whodb_platform_source_content), so differentiation is implied rather than declared.

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?

'Use this to understand source shape without exposing credentials' gives a clear when-to-use condition tied to credential safety. No explicit when-not or named alternative appears, so an agent must infer that source_fields/source_test cover other needs.

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

Deploy Server