Skip to main content
Glama
beckettlab

Beckett — MCP for Godot

by beckettlab

batch_execute

Run multiple Godot editor tool calls in a single ordered batch, stopping on failure and rolling back scene edits via undo history to keep authoring steps atomic.

Instructions

Run several tool calls in one request, in order. steps = [{tool, args}]. Stops at the first failure (stop_on_error, default true). When a step fails, scene edits made by the batch are rolled back via the editor undo history (rollback, default true) — file/resource writes are not. Use to collapse multi-step authoring (create node → set props → attach script) into one atomic call. ok per step means the handler completed - verify EFFECTS with a trailing read-back step (assert_scene / assert_node_state / a get_*) before trusting a mutation batch.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
stepsYesordered [{tool: name, args: {...}}]
rollbackNoundo scene edits on failure (default true)
stop_on_errorNohalt on first failure (default true)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.10.1
  2. Removedv1.10.0
  3. First observedv1.0.0

TDQS

A4.7/5.0
Behavior5/5

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

Description discloses key behavioral traits: stops on first failure with default true, rolls back scene edits via editor undo history, does not roll back file/resource writes, and clarifies that per-step 'ok' only means handler completion. These nuances go well beyond the annotations and are critical for correctly using the tool.

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?

Description is front-loaded with the core purpose, then packs defaults, rollback semantics, usage suggestion, and verification warning into a compact paragraph. Every sentence carries information; no filler or repetition.

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 a powerful meta-tool with no output schema, the description covers execution order, failure behavior, rollback scope, per-step success meaning, and recommends verification steps. Nothing essential for an agent to decide whether and how to invoke batch_execute is missing.

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?

Input schema already documents all three parameters at 100% coverage, so the baseline is 3. The description adds behavioral meaning for 'rollback' ('scene edits...rolled back...file/resource writes are not') and for 'stop_on_error' ('Stops at the first failure'), plus the steps shape, elevating it above schema-only repetition.

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?

Description opens with a clear verb and resource: 'Run several tool calls in one request, in order.' It explicitly frames the tool as a batch/meta executor and gives a concrete structural example ('steps = [{tool, args}]), distinguishing it from single-operation sibling tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicit guidance appears: 'Use to collapse multi-step authoring...into one atomic call,' and it warns to verify effects with a trailing read-back step. It does not explicitly say when not to use batch_execute compared to separate calls, but the sequencing/failure semantics imply that.

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