Skip to main content
Glama
dfridkin

clawops

by dfridkin
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

Deploy OpenClaw (End-to-End Workflow)

clawops_workflow_deploy_app
DestructiveIdempotent

Deploy a self-hosted OpenClaw instance to AWS, GCP, Azure, or local. Plans, confirms, provisions, waits for a healthy gateway, then returns the URL.

Instructions

Single-tool workflow that takes a user from "I want to deploy OpenClaw to " to a verified, healthy gateway. Internally: plan → user confirms (elicitation) → up → wait for healthy → return URL.

Use when: the user expresses end-to-end deployment intent ("deploy to AWS", "spin up an OpenClaw on GCP for me").

Do NOT use when: the user is mid-deployment and only needs one step (e.g., they already have a plan; use clawops_apply). Do NOT use for destroying or updating — separate workflows.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
regionNoCloud region, in the provider's own spelling (us-east-1, us-central1, eastus). Omitted = the provider's default
providerYesCloud to deploy to. Omitted = the default provider in ~/.clawops/config.json
stackNameNoName for the new stack. Omitted = the default stack name in ~/.clawops/config.jsondefault
instanceTypeNoMachine size: a clawops alias (micro|small|medium|large|gpu) or a type the cloud names itself, e.g. t3.smallsmall

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changedv2.1.3
    • addedInput schema / properties / instanceType / description
      Added value: +"Machine size: a clawops alias (micro|small|medium|large|gpu) or a type the cloud names itself, e.g. t3.small"
    • addedInput schema / properties / provider / description
      Added value: +"Cloud to deploy to. Omitted = the default provider in ~/.clawops/config.json"
    • addedInput schema / properties / region / description
      Added value: +"Cloud region, in the provider's own spelling (us-east-1, us-central1, eastus). Omitted = the provider's default"
    • addedInput schema / properties / stackName / description
      Added value: +"Name for the new stack. Omitted = the default stack name in ~/.clawops/config.json"
  2. First observedv2.1.1

TDQS

A4.4/5.0
Behavior4/5

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

The description adds valuable context beyond the annotations: it reveals the internal sequencing ('plan → user confirms (elicitation) → up → wait for healthy → return URL') and the completion condition. It does not explicitly discuss destructive side effects, but the annotations already carry destructiveHint: true, so the description is not misleading and the annotations cover that risk.

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 tightly structured: the workflow is front-loaded in the first sentence, followed by crisp use-case and exclusion rules. There is no filler or repetition of schema content, and every sentence earns its place.

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?

For a complex workflow tool with no output schema, the description covers the overall lifecycle, user confirmation requirement, health verification, and the returned URL. It leaves minor gaps around failure behavior and output formatting, but these are secondary given the schema and annotations already cover parameter defaults and safety signals.

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 the schema documents all four parameters clearly with defaults, enums, and provider-specific spelling notes. The description adds no new parameter-level detail, which is acceptable given the schema already carries the semantic load; a baseline 3 is appropriate.

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 names a specific verb ('deploy OpenClaw') and a clear scope: an end-to-end workflow from intent to a 'verified, healthy gateway.' It also distinguishes itself from siblings by calling out that it is a 'Single-tool workflow' and explicitly marking 'clawops_apply' as the one-step alternative, so an agent can identify it without opening schemas.

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 gives explicit 'Use when' and 'Do NOT use when' guidance with concrete user phrasing examples ('deploy to AWS', 'spin up an OpenClaw on GCP for me'). It names the alternative tool (clawops_apply) and excludes destroy/update cases, leaving no ambiguity about when to select this workflow.

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