Skip to main content
Glama
Sign In

Kalpana Batch

by one.kalpana
OverviewDiscussionsAdmin

Render a batch (spends credits)

run_batch
DestructiveIdempotent

Renders a batch: every pending job is queued, and the call returns once they are queued. Images render in the background; track them with get_batch and collect them with get_batch_outputs. It spends the workspace organization's credits for the pending jobs: create_batch's creditCost, unless jobs were added or removed since. When the balance is too low nothing is queued, the error says not enough credits, and the batch stays a draft. A successful run publishes the draft; update_batch can still add, change or remove its pending jobs. An archived batch returns an error, and a batch with a pending job on a deleted template returns Template not found and queues nothing. Jobs reset to pending by update_batch or update_job render on the next call. If the workspace has webhook endpoints, they receive the results unless webhooks is false. Run it only after the user agrees to the cost; check rows first with validate_batch. Needs batches:create on the connection and renders:create in the user's workspace role.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "batchId": "<batchId>"
    },
    "name": "run_batch"
  }
}

Input Schema

NameRequiredDescriptionDefault
batchIdYesBatch ID returned by create_batch or list_batches
webhooksNoWhether this run sends its results (batch.completed, job.completed) to the workspace's webhook endpoints. Omit to keep the batch's setting, which is on; pass false only when the user asks not to notify their endpoints

Output Schema

NameRequiredDescriptionDefault
failedYesJobs that could not be queued
messageYes
dispatchedYesPending jobs queued by this call; 0 on a repeat call

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changed
    • removedInput schema / additionalProperties
      Removed value: -false
    • addedInput schema / properties / batchId / pattern
      Added value: +"^([0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{12})$"
    • addedOutput schema / properties / dispatched / maximum
      Added value: +9007199254740991
    • addedOutput schema / properties / failed / maximum
      Added value: +9007199254740991
  2. First observed

TDQS

A4.4/5.0
Behavior4/5

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

Well beyond the annotations: it discloses the credit-spend model, that rendering continues in the background, that a successful run publishes the draft and leaves it editable via update_batch, the low-balance failure (nothing queued, batch stays a draft), the archived-batch and deleted-template errors, and the webhook side effect. The one gap is that idempotentHint=true is never reconciled with the fresh credit charge on a repeat call; a line clarifying that a re-run with no pending jobs consumes nothing would close it.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with the core semantics and effect, then progressively adds failure modes, permissions and side effects in rough order of decision value. It is dense — ten sentences — and the credit-cost sentence is slightly tangled ("create_batch's creditCost, unless jobs were added or removed since"), but no sentence is filler.

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 mutation that spends money and has no undo, this covers cost, timing, publish semantics, required scopes (batches:create and renders:create), webhook side effects, and three distinct error branches. With an output schema present, no return-value explanation is needed, so nothing material is missing.

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% and both parameters already carry detailed descriptions, so the baseline is 3. The description only echoes the webhook behavior ("they receive the results unless webhooks is false") and adds no format or edge-case detail for batchId beyond what the schema states.

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?

Names a specific verb and resource ("Renders a batch") and immediately defines the exact semantics: every pending job is queued and the call returns at queue time, not at render time. That distinguishes it clearly from run_job (single job), create_batch (draft creation) and get_batch_outputs (collection).

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?

Gives an explicit precondition ("Run it only after the user agrees to the cost"), names the alternative to use first ("check rows first with validate_batch"), and routes the agent to get_batch/get_batch_outputs for tracking results. When-not-to-use is also covered via the archived-batch and insufficient-credit failure modes.

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

All Kalpana Batch toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources