Skip to main content
Glama
Sign In
whodb-cli

whodb-cli

Official
by clidey
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Go
Remote

whodb_platform_runtime_readiness

Read-onlyIdempotent

Summarize a selected project's runtime readiness before function, transform, AI provider, or secret work; returns configured resources, timestamped evidence, and optional latest function run details.

Instructions

Summarize selected-project runtime readiness.

Use this before function, transform, AI provider, or secret work. It returns configured resources and timestamped evidence. Reachability and verification stay unknown unless supported by evidence. Optional function_id inspects the latest persisted run without executing it; historical success is not current worker health. Unavailable inventories are partial results with warnings. Accepts workspace {host, org, project} for per-call targeting without changing defaults.

Input Schema

NameRequiredDescriptionDefault
goalNoOptional user goal used to keep suggested actions relevant.
fieldsNoTop-level output fields to include, for example actions, warnings, goal.
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.
omit_filesNoOmit root folder file and folder summaries. Defaults to false.
function_idNoFor runtime readiness, inspect the latest persisted run of this function without executing it.
omit_lineageNoOmit project lineage summary. Defaults to false.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.136.0
    • addedInput schema / properties / function_id
      Added value: +{
+  "description": "For runtime readiness, inspect the latest persisted run of this function without executing it.",
+  "type": "string"
+}
  2. Addedv0.135.0

TDQS

A3.9/5.0
Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint and openWorldHint, but the description adds genuinely new behavioral context: unknown reachability/verification unless evidence-backed, historical success is not current worker health, and unavailable inventories yield partial results with warnings. It also discloses that workspace targeting is per-call and does not change session defaults, which is not obvious from the annotations.

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?

The core action and the 'use before X' guidance are front-loaded, and each later sentence adds a distinct caveat rather than padding. It is dense and reads as a run-on block of caveats, which slightly impedes scanning.

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 no output schema and six optional parameters in a nested workspace object, the description does the needed work: it names the returned categories, explains partial/warning outcomes, and describes default-resolution order. Only the absence of sibling disambiguation against other health/status tools keeps it short of a 5.

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 per the rubric the baseline is 3. The description restates the function_id non-execution semantics and the workspace precedence order (session_use then process/saved defaults), which is modest added value over schema text that already says essentially the same thing.

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: 'Summarize selected-project runtime readiness', and immediately clarifies what that means by naming the returned content ('configured resources and timestamped evidence'). It does not explicitly differentiate itself from nearby siblings like whodb_platform_project_health, whodb_platform_status or whodb_platform_setup_status, so an agent still has to infer which of the several health-ish tools to pick.

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 function, transform, AI provider, or secret work' gives a concrete triggering condition, and the function_id sentence clarifies a distinct mode (inspect latest persisted run without executing). What is missing is explicit when-not guidance or a named alternative such as project_health or status for agents who want a different health angle.

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