Skip to main content
Glama
dfridkin

clawops

by dfridkin
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

Apply Maker Plan

clawops_apply
Destructive

Apply a previously generated deploy plan to execute exact deploy or destroy actions. Needs an existing plan file; generate one first if missing.

Instructions

Apply a previously-generated Maker plan (deploy-plan.schema.json). Deterministic — the plan describes exactly what will be created.

Use when: the user has a plan file path and wants to apply it. This is the agent-friendly path for any deploy/destroy operation.

Do NOT use when: there's no plan file — generate one first with clawops_plan.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
yesNoSkip the confirmation and apply immediately. Only when the user has already approved this specific plan
planPathYesAbsolute path to plan JSON (R7)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv2.1.3
    • addedInput schema / properties / planPath / description
      Added value: +"Absolute path to plan JSON (R7)"
    • addedInput schema / properties / yes / description
      Added value: +"Skip the confirmation and apply immediately. Only when the user has already approved this specific plan"
  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?

Annotations already provide destructiveHint=trueaint and idempotentHint=false, so the safety profile is partially covered. The description adds valuable behavioral context by labeling the operation 'Deterministic' and clarifying that the plan describes exactly what will be created, while also noting it is the agent-friendly path for deploy/destroy operations.

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 compact, front-loaded with the core purpose, and uses short, scannable 'Use when' and 'Do NOT use when' sections. Every sentence earns its place with no redundancy or filler.

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 two-parameter tool with no output schemachers, the description covers the key context: when to use it, when not to use it, the deterministic behavior, and the relationship to plan generation. It doesn't spell out the return value or confirmation flow, but annotations and the schema cover the critical safety and parameter aspects.

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 both parameters are already fully documented in the schema. The description doesn't add syntax or additional meaning beyond pointing to the plan file and the concept of applying it, which is sufficient but not above the baseline.

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 states a specific verb ('Apply') and resource ('previously-generated Maker plan'), and explicitly links it to deploy-plan.schema.json. It also differentiates from clawops_plan by specifying 'previously-generated' and is clear about the deterministic nature of the action.

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 provides explicit 'Use when' and 'Do NOT use when' guidance, including the exact alternative (clawops_plan) and the condition that selects it ('no plan file'). This leaves no ambiguity for an agent deciding between tools.

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