Skip to main content
Glama

Run one task over many inputs

run_batch

Run one task over many inputs in one call: for repeated runs of the same task, one round trip rather than one per run. Priced the same per item as a single run, with no fee for batching: each item is quoted, reserved and charged on its own, and only a delivered result is charged. Give id and items, 1 to 100 objects of the task's inputs. Every item is checked first: a bad item is refused alone and the others run. Identical items run once and the answer maps back to each position. At most 5 run at once. max_cost_usd caps the whole batch: no item starts if what is charged, plus what is held, plus its own quote could pass it, and items left over answer not_started with nothing charged. A provider that is temporarily unavailable stops only the items it would serve. The answer comes within about 45 seconds: each item in input order has its position, state, rows, charged_usd, error and execution_id, then the totals. Items still going, and rows that did not fit, are read with capability_run_status. An item with rows also has results_page and csv_url: give the person those links instead of writing the rows out again. Sending the same call again the same UTC day answers the same runs with no new charge and starts what did not start; a new idempotency_key runs the items again. A task that is unknown or not ready refuses the whole call, free. NOT for: one run alone, which is run_capability.

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": {
      "id": "<id>",
      "items": "<items>"
    },
    "name": "run_batch"
  }
}

Input Schema

NameRequiredDescriptionDefault
idYesA task id or tool id from capability_search or capability_inspect. One task for the whole batch.
tagNoOptional: a label for every run in this batch, such as the customer or project it is for: 1 to 64 lowercase letters, digits, dots, dashes or underscores. Activity shows runs and cost by tag. It stays in Ahel and is never sent to a provider.
itemsYes1 to 100 objects, each the task's inputs for one run, by name, as run_capability's arguments.
max_itemsNoMost rows each item collects, 1-100. Default 10.
max_cost_usdNoOptional: the most the whole batch may cost, in USD, such as "2.50". Without it the workspace's normal limits apply.
idempotency_keyNoOptional: your own key for this batch, 8 to 200 letters, digits, dots, underscores, colons or hyphens. The same key and item answers the same run with no new charge; a new key runs it again. Left out, the same call the same UTC day is the same batch.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.8/5.0
Behavior5/5

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

Annotations declare non-readonly, open-world, non-idempotent, non-destructive, but the description goes far beyond them: per-item quoting/reservation/charging with no charge for failed items, per-item validation isolation, deduplication of identical items, a concurrency cap of 5, max_cost_usd admission logic with not_started outcomes, provider-unavailability scoping, ~45s answer window, and same-day idempotency semantics. That is exactly the behavioral context annotations cannot express.

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?

The description is long but almost every sentence carries distinct operational information, front-loaded with purpose and closing with the exclusion. It is dense prose in a single block; a few sentences (e.g. the per-item pricing restatement) could be tightened, but little is truly wasted.

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 6-parameter mutation tool with no output schema and open-world side effects, the description covers cost semantics, partial failure behavior, concurrency, response shape (position, state, rows, charged_usd, error, execution_id, totals), pagination via capability_run_status, and idempotency. The response-shape detail compensates for the absent output schema.

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, but the description adds real meaning: items are 'the task's inputs' structured as run_capability's arguments, the 1-100 bound is restated, and max_cost_usd is explained operationally (charged + held + own quote check, leftovers answer not_started with nothing charged). idempotency_key interaction with same-day dedup is also clarified.

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 plus scope: 'Run one task over many inputs in one call', and explicitly distinguishes itself from run_capability in the 'NOT for' clause. An agent can tell instantly that this is the fan-out variant of a single run.

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?

Explicit when-to-use (repeated runs of the same task, batching to save round trips) and explicit when-not ('NOT for: one run alone, which is run_capability'). It also names capability_run_status as the follow-up for incomplete items, giving a full routing picture.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.