clawops

Initialise clawops Config

clawops_init

Initialize a clawops stack by writing local config for provider, region, state backend, and SSH key. Use it before deploying or when no config exists; it only creates local settings and provisions nothing.

Instructions

Register a stack and write ~/.clawops/config.json: the provider, the state backend, the region, and an SSH key pair generated if one is not already there. Nothing is provisioned and nothing is charged; this only creates local configuration.

Use when: any other clawops tool reports that there is no config, or the user wants to add a second stack alongside the ones they have. This is the first call on a machine that has never run clawops — a fresh container, a new laptop, a sandbox.

Adding a stack is additive and safe: existing stacks are kept. Overwriting one needs force: true, because changing a state backend orphans the Pulumi state it points at — the infrastructure stays up and clawops can no longer see or destroy it.

For aws, gcp and azure, stateUrl can be omitted and clawops names a bucket from the account it can see; that needs cloud credentials in the environment, so in a sandbox pass stateUrl explicitly. The local provider needs host instead, and no cloud account at all.

Do NOT use when: the user wants to deploy — that is clawops_up, after this. Credentials are never passed here: clawops reads them from the environment (R6).

Input Schema

TableJSON Schema

Name	Required	Description
`host`	No	[local only] Hostname or IP of the machine to manage. Required when provider is local
`force`	No	Overwrite a stack that already exists. Refused without it, because replacing a state backend orphans the state it points at
`region`	No	Cloud region in the provider's own spelling. Omitted = us-east-1 (aws), us-central1 (gcp), eastus (azure)
`sshPort`	No	[local only] SSH port. Omitted = 22
`sshUser`	No	[local only] SSH login user. Omitted = root
`provider`	Yes	Which cloud this stack deploys to, or 'local' for a machine you already have
`stateUrl`	No	Where Pulumi state lives, e.g. s3://bucket/clawops, gs://bucket/clawops, azblob://container. Omitted = clawops names one from the cloud account it can see, which needs credentials
`stackName`	No	Name for the stack, used by every later call. Omitted = "default"

Schema Changelog

Changes observed during successful MCP inspections.

Addedv2.1.3Sep 23, 2026

TDQS

A4.9/5.0

Behavior5/5

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

The description adds substantial behavior beyond annotations: SSH key pair generation, additive safety of stacks, the force:true overwrite path orphaning Pulumi state, credential handling from environment, and provider-specific bucket naming behavior. The annotations only say read-only/destructive/idempotent flags, so this context is genuinely valuable and consistent.

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 longer than average, but every sentence carries operational information: safety, prerequisites, provider nuances, and routing to the right sibling. It is front-loaded with the core purpose and organized into scannable paragraphs.

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?

For an 8-parameter initialization tool with no output schema, the description covers purpose, safety, prerequisites, provider-specific parameter rules, exclusions, and sibling routing. An agent has everything it needs to decide when to call it and how to configure it correctly.

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?

Schema coverage is 100%, so the baseline is 3. The description adds inter-parameter meaning beyond the schema: omitting stateUrl makes clawops derive a bucket needing credentials, local requires host instead of cloud account, and force:true is tied to the state-backend orphaning warning. This is a clear improvement over the schema alone.

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: 'Register a stack and write ~/.clawops/config.json', and names exactly what it creates. It clearly distinguishes itself from deployment tools by stating 'Nothing is provisioned and nothing is charged; this only creates local configuration.'

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?

It gives explicit use conditions: when no config exists, when adding a second stack, or on a fresh machine. It also names an exclusion and alternative: 'Do NOT use when: the user wants to deploy — that is clawops_up, after this.'

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Initialise clawops Config

Instructions

Input Schema

Schema Changelog

TDQS

Other Tools