Skip to main content
Glama
dha-aa
by dha-aa

Batch

batch
Destructive

Run up to 50 tool calls in order in one call (prefer it for multi-step builds). "$N.path" in args is that value from step N's result (from 1), e.g. "$1.id", "$2.layers.0.id"; name a step (as: "title") to use "$title.id" instead.

Instructions

Run up to 50 tool calls in order in one call (prefer it for multi-step builds). "$N.path" in args is that value from step N's result (from 1), e.g. "$1.id", "$2.layers.0.id"; name a step (as: "title") to use "$title.id" instead. "$$" is a literal $ ("$$99"). defaults: {tool: args} merged under every step of that tool (shared style, comp_id). All steps are checked before any runs; a step that fails in After Effects stops the batch with the results so far and a batch_id for resume. Each step is its own undo step. Not preview_frame, run_jsx or open_project.

Input Schema

NameRequiredDescriptionDefault
stepsYes
resumeNoAfter a failure: the same steps, fixed, run from step `from` with the earlier results
resultsNoauto (default): each result whole up to 600 characters, larger ones cut to ids and names; all: everything; none: only the step countauto
defaultsNoPer tool: args every step of that tool starts from (its own args win; nested objects merge)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv2.23.0
    • removedInput schema / properties / defaults / additionalProperties / additionalProperties
      Removed value: -{}
    • removedInput schema / properties / steps / items / properties / args / additionalProperties
      Removed value: -{}
  2. First observedv2.22.0

TDQS

A5/5.0
Behavior5/5

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

Beyond annotations, the description discloses important behavior: all steps are validated before any execution, a failing step stops the batch with partial results and a batch_id for resume, and each step is its own undo step. These details materially help an agent understand execution semantics for a destructive, non-idempotent batch operation.

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 dense but appropriately sized for a complex batch tool. The core purpose is front-loaded, and each clause adds operational value: substitution syntax, failure behavior, undo granularity, and excluded tools.

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?

Given the tool's complexity, nested schema, and lack of an output schema, the description covers the important invocation semantics: ordering, limits, validation, failure/resume behavior, defaults, and result substitution. No major behavioral gap remains for an agent to call it correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The description adds substantial meaning beyond the schema, especially for the steps array: it explains "$N.path" result substitution, step naming via "as", and escaping with "$$". It also clarifies defaults merging behavior, which is central to using the nested step objects correctly.

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 and resource: run up to 50 tool calls in order in one call. It also distinguishes the tool from nearby alternatives by explicitly naming preview_frame, run_jsx, and open_project as not appropriate for batching.

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 clearly recommends the tool for multi-step builds and names excluded tools, giving an agent concrete when-to-use and when-not-to-use guidance. This is explicit routing guidance rather than implied usage.

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