whodb-cli

Official

Overview Schema Source Related Servers Discussions Admin

whodb_platform_source_objects

Read-onlyIdempotent

Browse read-only objects such as tables and views in a hosted WhoDB source by name or ID, with optional parent, kind filters, field selection, and pagination.

Instructions

Browse objects in one hosted WhoDB source.

Use the source name or id from whodb_platform_sources. Parent refs use kind:path, for example schema:public. This tool is read-only. Prefer fields such as ["Name", "Kind", "HasChildren"] while browsing. Accepts workspace {host, org, project} for per-call targeting without changing defaults.

Input Schema

Name	Required	Description
`kinds`	No	Object kinds to include, for example Table or View
`fields`	No	Optional top-level output fields to include in items
`parent`	No	Parent object ref as kind:path, for example schema:public
`source`	Yes	Hosted source id or name
`page_size`	No	Maximum objects to return
`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.
`page_offset`	No	Object offset

Output Schema

Name	Required	Description
`count`	Yes
`error`	No
`items`	No
`scope`	No
`fields`	No
`objects`	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
`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

A3.5/5.0

Behavior3/5

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

Annotations already declare readOnlyHint, idempotentHint, and openWorldHint, so 'This tool is read-only' restates rather than adds. The description does add real context beyond annotations: the parent ref format (kind:path), source discovery path, and the workspace per-call targeting semantics with its precedence order. No pagination or return-shape detail, but the output schema exists.

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 short sentences, front-loaded with the core action, then prerequisites, then recommendation, then targeting. No filler or redundancy. Slightly choppy flow but every sentence carries information.

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 annotations covering safety/idempotency, an output schema present, and 100% parameter coverage, the description supplies the remaining needed context: where source names come from, parent ref syntax, and workspace override precedence. Only the distinction from adjacent browse tools 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 coverage is 100%, so the schema documents every parameter and the 3 baseline applies. The description adds modest value by suggesting concrete field names for the fields parameter and repeating the parent kind:path convention, but nothing substantial beyond the schema.

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: 'Browse objects in one hosted WhoDB source.' That distinguishes it from mutation siblings like whodb_platform_create and from whodb_platform_source_rows/columns conceptually, but it never explicitly differentiates itself from those closely-related browse tools. Clear purpose, weak sibling differentiation.

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

Usage Guidelines3/5

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

Gives a useful prerequisite chain ('Use the source name or id from whodb_platform_sources') and a browsing hint ('Prefer fields such as ["Name", "Kind", "HasChildren"]'). However, it never says when to choose this over whodb_platform_source_rows, whodb_platform_source_columns, or whodb_platform_source_content, so the agent must infer from names alone.

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

Deploy Server