Skip to main content
Glama

Run a pipeline across many data sources (batch)

run_pipeline_batch

Execute a pipeline configuration across multiple source paths or globs, overriding the path per source. Returns per-source statuses, errors, and totals for independent runs.

Instructions

Execute one pipeline config for multiple explicit source paths or globs, overriding config.path for each source. Each source runs independently; returns per-source statuses/errors and totals. For event reductions, preview each source to be reduced and obtain confirmation of the batch scope before executing. Tasks may write files or contact external services. Use run_pipeline for a single source. A glob matching nothing is treated as a literal path.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
pathsYes
configYes

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv2.0.1

TDQS

A4.7/5.0
Behavior4/5

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

Annotations indicate side effects (readOnlyHint=false), external interactions (openWorldHint=true), and non-idempotency (idempotentHint=false), but the description adds crucial context: 'Tasks may write files or contact external services' reinforces the side-effect risk. It also explains that each source runs independently and returns per-source statuses/errors and totals, which is behavior not in the annotations. The glob-literal-path fallback is a specific behavioral disclosure. This adds value beyond annotations, though it doesn't exhaustively cover all behavioral nuances (e.g., partial failure handling), so a 4 is appropriate.

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 five sentences, each serving a distinct purpose: the core action, the independent execution and return shape, the confirmation requirement for event reductions, the side-effect warning, and the single-source alternative plus glob edge case. It is front-loaded with the primary function, and there is 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?

Given the tool's complexity (batch execution, side effects, potential confirmation requirement) and the presence of an output schema (which presumably details the return structure), the description covers what an agent needs: the operation, how config.path is overridden, side-effect caveats, the guidance to preview for event reductions, the single-source alternative, and the glob edge case. Nothing critical for a correct invocation 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?

Schema description coverage is 0%, so the description must compensate. It does: 'paths' are described as 'explicit source paths or globs', and the config is 'one pipeline config' with the behavior that it overrides config.path for each source. This explains the meaning and relationship of both parameters. While it doesn't enumerate all possible config fields, it gives sufficient semantics for an agent to construct valid inputs.

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 action: 'Execute one pipeline config for multiple explicit source paths or globs'. It clearly identifies the resource (pipeline config) and the batch nature, and explicitly differentiates from the sibling run_pipeline by noting 'Use run_pipeline for a single source.' An agent can unambiguously determine what this tool does and when to select it.

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?

The description provides explicit usage guidance: it tells the agent to use run_pipeline for a single source instead, and instructs to preview sources before execution for event reductions and obtain confirmation of batch scope. This directly addresses when to use and when not to use the tool, going beyond mere implication. It also warns about the glob-matching-nothing edge case, adding operational guidance.

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