whodb-cli

Official

Overview Schema Source Related Servers Discussions Admin

whodb_platform_source_fields

Read-onlyIdempotent

Lists connection fields for a hosted WhoDB source type to discover required fields and defaults before source creation or draft connection tests; read-only and exposes no credentials.

Instructions

List connection fields for one hosted WhoDB source type.

Use this before source creation or draft connection tests to discover required fields and defaults. This tool is read-only and does not expose credentials. Prefer fields such as ["Key", "Kind", "Required", "LabelKey"] unless full field metadata is needed. Accepts workspace {host, org, project} for per-call targeting without changing defaults.

Input Schema

Name	Required	Description
`fields`	No	Optional top-level output fields to include in items
`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.
`source_type`	Yes	Hosted source type id

Output Schema

Name	Required	Description
`count`	Yes
`error`	No
`items`	No
`scope`	No
`fields`	Yes
`commands`	No
`recovery`	No
`warnings`	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
`source_type`	No
`setup_status`	No
`selected_fields`	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.3/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 safety profile is covered; the description adds non-obvious context on top: no credential exposure, and that workspace targeting applies per-call without mutating session defaults. It does not describe result size or pagination, which keeps it from a 5.

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?

Purpose is front-loaded and every sentence carries information (timing, safety, field preference, targeting). Slightly dense with four distinct concerns packed into one short block, but no filler.

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?

With an output schema present the return shape needn't be explained, and the description covers purpose, when to call, credential safety, field selection, and the workspace resolution fallback chain. Only the explicit alternative sibling for full metadata is missing.

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, but the description adds real value by naming candidate field keys ("Key", "Kind", "Required", "LabelKey") the schema leaves abstract, plus a concise restatement of per-call workspace targeting vs. session defaults.

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+resource (list connection fields for one hosted source type) and scopes it to a single source_type, which cleanly separates it from siblings like whodb_platform_source_types, source_constraints, and source_config.

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 before source creation or draft connection tests" gives explicit timing and intent, and "Prefer fields such as [...] unless full field metadata is needed" gives a selection rule. It never names the sibling to use instead for the full-metadata case, so it falls short of explicit alternatives.

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

Deploy Server