Skip to main content
Glama
dfridkin

clawops

by dfridkin
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

Run Diagnostics

clawops_doctor
Read-onlyIdempotent

Diagnose OpenClaw gateway problems with local and remote checks of runtime, config, credentials, and health. Run before deploying, upgrading, or troubleshooting.

Instructions

Run clawops's diagnostics and return the report: Node and Pulumi runtime, config, SSH key and known_hosts, cloud credentials per configured provider, and the supported OpenClaw range. With stackName, also contacts the host for container state, the deployed OpenClaw version, a real gateway health probe, whether the port is published to the internet, disk usage on the state directory, log rotation, and hardening drift.

Use when: something is not working and you do not yet know what; before any deploy, upgrade or migration; or to find out which OpenClaw version a gateway is actually running.

Do NOT use when: you already know the problem and want to fix it. This tool only reports — it changes nothing, and never runs openclaw doctor --fix. No tool repairs a gateway: clawops gateway update is CLI-only, so tell the user to run it themselves, after clawops backup create.

Every check carries a status: fail (something is wrong that clawops can name), warn (worth knowing, not broken), info (did not apply). ok is false only when something failed — a fresh machine with no stacks is full of warnings and healthy.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
stackNameNoStack to include remote checks for. Without it, only the local machine is checked — no SSH connection is made.
failuresOnlyNoReturn only failing and warning checks. Passing checks are counted, not listed.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv2.1.3
    • addedInput schema / properties / failuresOnly / description
      Added value: +"Return only failing and warning checks. Passing checks are counted, not listed."
    • addedInput schema / properties / stackName / description
      Added value: +"Stack to include remote checks for. Without it, only the local machine is\nchecked — no SSH connection is made.\n"
  2. First observedv2.1.1

TDQS

A4.9/5.0
Behavior5/5

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

Beyond annotations that declare read-only and idempotent hints, the description states 'it changes nothing, and never runs `openclaw doctor --fix`,' reinforcing the non-destructive behavior. It also explains the status semantics (fail/warn/info) and the meaning of `ok`, which is crucial for interpreting the report, and discloses that with `stackName` it contacts the host remotely.

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?

The description is organized into three distinct paragraphs: scope, usage criteria, and output semantics. Every sentence adds necessary information (what, when, when not, what it changes, how to read results) without fluff, and it is front-loaded with the core diagnostic purpose.

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?

The tool has no required parameters and no output schema, so the description carries the burden of explaining returns. It lists all check categories, describes the status values, and clarifies the meaning of `ok` and warnings, giving an agent enough context to invoke the tool and interpret results. The usage restrictions and behavioral notes fill gaps that annotations alone would not cover.

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?

While the schema already documents both parameters with 100% coverage, the description adds semantic detail by listing the additional remote checks triggered by `stackName` (container state, deployed version, gateway probe, port exposure, disk usage, log rotation, hardening drift) and explains the status categories that `failuresOnly` filters on. This enriches the meaning beyond the schema's brief descriptions.

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?

The description opens with a specific verb and resource: 'Run clawops's diagnostics and return the report,' then enumerates the exact checks performed (Node/Pulumi runtime, config, SSH key, cloud credentials, etc.). It clearly differentiates from siblings by framing itself as the 'do not know what's wrong' diagnostic tool, distinct from `clawops_status`, `clawops_harden`, or `clawops_monitor`.

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?

The description includes explicit 'Use when' and 'Do NOT use when' sections, giving the agent clear decision criteria: use it for unknown problems, before deploy/upgrade/migration, or to discover the actual gateway version. It explicitly says not to use when the problem is already known and wants a fix, and it points out that no tool repairs a gateway, directing the user to CLI commands instead.

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