Skip to main content
Glama

batch_run

Run multiple prompts in parallel with bounded concurrency and auto-retry. Picks the fastest model, automatically retries failed items on alternatives, and supports incremental JSONL output resumable on interruption.

Instructions

Run multiple prompts in parallel with bounded concurrency and auto-retry.

For batch workloads: translation pipelines, data extraction, classification, content generation. Picks the fastest model and runs all prompts through it. Failed items are automatically retried on alternate models.

Each prompt dict should have a "prompt" key and optional "system_prompt" (overrides the top-level system_prompt) and "metadata" keys for tracking.

When results_file is set, each completed item is appended as a JSON line immediately. If interrupted, the file contains all completed items and can be resumed (already-completed indices are skipped).

Args: prompts: List of {"prompt": "...", "system_prompt": "...", "metadata": {...}} system_prompt: Default system prompt for all items (per-item overrides) model_id: Specific model to use (skips scanning). Use list_models() to browse. provider: Limit to a specific provider min_tier: Minimum quality tier when auto-selecting (default "A") free_only: If true, only use free models max_tokens: Max response tokens per item (default 4096) temperature: Sampling temperature (default 0.0) concurrency: Max parallel requests (default 5) retry_on_fail: Auto-retry failed items on alternate models (default true) results_file: Path to JSONL file for incremental writes and resume support

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
promptsYes
min_tierNoA
model_idNo
providerNo
free_onlyNo
max_tokensNo
concurrencyNo
temperatureNo
results_fileNo
retry_on_failNo
system_promptNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes
Behavior4/5

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

No annotations provided, so the description carries the full burden. It discloses key behaviors: bounded concurrency, auto-retry, model selection, incremental results file, and resume support. It does not mention authentication or rate limits, but these are less critical for this tool.

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 front-loaded with a one-line summary followed by context and a structured args list. It is slightly long but every sentence adds value. Could be slightly more concise, but overall well-organized.

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?

Given 11 parameters, no annotations, but an output schema exists (so return values are covered elsewhere). The description covers input semantics, behavioral details, and use cases. It may lack edge-case handling, but is sufficient for most batch workloads.

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?

Schema coverage is 0%, so the description must compensate. It lists all 11 parameters with clear descriptions, including structure for 'prompts', defaults for many, and cross-reference to list_models() for model_id. No parameter is left unexplained.

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 clear verb-resource: 'Run multiple prompts in parallel with bounded concurrency and auto-retry.' It lists specific use cases (translation pipelines, data extraction, etc.) and distinguishes from siblings like 'run' (single prompt) and 'batch_judge' (judging).

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?

The description explicitly states 'For batch workloads' and explains auto-retry and resume, giving good context. However, it does not explicitly contrast with alternatives like 'run' or 'batch_judge', though the intent is clear from the use cases.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/srclight/model-radar'

If you have feedback or need assistance with the MCP directory API, please join our Discord server