clawops
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
| prompts | {
"listChanged": true
} |
| resources | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
| deploy-to-aws | Step-by-step guide to deploy OpenClaw on AWS |
| recover-failed-stack | Diagnostic playbook for a failed or unhealthy clawops stack |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
| current-context | Active stack name, provider, and region |
| stacks | All configured stacks |
TDQS
Scored across 19 tools
Many tools have overlapping or unclear purposes, such as clawops_status, clawops_monitor, clawops_doctor, and clawops_task_status, which all seem related to checking system state. Without descriptions, it's difficult for an agent to distinguish between these tools, leading to likely misselection.
All tools follow a consistent pattern with the 'clawops_' prefix and snake_case naming (e.g., clawops_config_get, clawops_config_set). However, verb usage varies (status, plan, destroy, harden) and some names like 'clawops_doctor' or 'clawops_up' are less conventional, but the overall pattern is predictable.
The server exposes 19 tools, which falls into the 'heavy' range (16-25). While the breadth suggests a comprehensive DevOps operations tool, the count feels slightly over-scoped for a single server, though it's not extreme enough to be detrimental.
The tool surface covers a wide range of operations: configuration management (get/set/unset/validate), lifecycle (plan/apply/destroy/up), monitoring (status/doctor/logs_tail/monitor), workflows (deploy_app/recover), and infrastructure control (stacks, agents, gateway). While some operations like a dedicated 'delete' or 'list' might be missing, the core workflows appear well-covered.