Skip to main content
Glama
Sign In
whodb-cli

whodb-cli

Official
by clidey
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Go
Remote

whodb_platform_session_use

Read-onlyIdempotent

Sets a default host, organization, and project for the current MCP session only, so later calls use that target without changing CLI config or affecting other sessions.

Instructions

Set the default host, organization, and project for this MCP session only.

Pass workspace {host, org, project}. The login is verified and the target is resolved to canonical IDs; later calls that omit workspace use it. Nothing is written to the CLI config, so other chats, terminals, and MCP sessions are unaffected. Use this once at the start of a chat that should stay on one host (for example UAT or production), then call whodb_platform_status to confirm. An explicit workspace on a later call still overrides it for that call. Call whodb_platform_session_clear to return to process/saved defaults. Accepts workspace {host, org, project} for per-call targeting without changing defaults.

Input Schema

NameRequiredDescriptionDefault
workspaceNoOptional 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

NameRequiredDescriptionDefault
errorNo
scopeNo
statusYes
recoveryNo
retryableNo
workspaceNoOptional 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_codeNo
request_idNo
session_scopeNo
suggested_toolsNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changedv0.136.0
    • 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"
+}
  2. Addedv0.135.0

TDQS

A4.6/5.0
Behavior5/5

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

Annotations already declare readOnly/idempotent/openWorld, and the description still adds substantive behavior: the login is verified, the target is resolved to canonical IDs, later calls inherit the default, and nothing is written to CLI config so other chats/terminals/sessions are unaffected. That persistence boundary is exactly the kind of context annotations cannot convey.

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 core action in sentence one, and each subsequent sentence adds a distinct fact (resolution, isolation, usage, override, undo). Slightly over-long: the final sentence largely repeats the per-call override point already made mid-paragraph.

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?

Output schema exists so return values need no explanation. For a session-state mutation tool the description covers what changes, what does not (CLI config, other sessions), how to verify it, how to revert it, and precedence rules for later calls — everything an agent needs to call it correctly.

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% and the nested workspace fields are individually documented, so the schema does the heavy lifting and baseline 3 applies. The description restates the shape ('Pass workspace {host, org, project}') and explains inheritance/override precedence, but the closing line ('Accepts workspace ... for per-call targeting without changing defaults') sits awkwardly against the schema's 'Optional target for this call only' wording, leaving the param's role on this specific tool slightly ambiguous rather than clarified.

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 and resource with an explicit scope qualifier: 'Set the default host, organization, and project for this MCP session only.' The 'session only' framing plus the named siblings (whodb_platform_session_clear, whodb_platform_status) make it trivially distinguishable from the many other whodb_platform_* 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?

Gives an explicit when ('use this once at the start of a chat that should stay on one host, for example UAT or production'), explicit alternatives (per-call workspace override, session_clear to return to defaults), and a verification step (call whodb_platform_status to confirm). Nothing about selection is left 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

Other Tools