Skip to main content
Glama
german-borisevich

Apache Zeppelin MCP Server

batch_run_paragraph

Run multiple notebook paragraphs in one call, in the order you specify, so dependent setup cells execute before later cells and parameters can be swept per paragraph.

Instructions

Run several paragraphs one after another in the given order, in a single call. Use this instead of many run_paragraph calls when you need a specific sequence of cells run — e.g. setup cells before the cells that depend on them. Paragraphs run sequentially (not in parallel) because cells typically share interpreter state, and this collapses N round-trips into one.

Each run item may carry its own dynamic form params. The top-level params dict is a shared
default merged under per-item params (the item wins on key conflicts). The same paragraph_id
may appear multiple times with different params — a parameter sweep in one call.

By default table output is limited to 50 rows and HTML output is omitted to save tokens.

Args:
    notebook_id: The notebook ID containing the paragraphs
    runs: Paragraphs to run in execution order, each {paragraph_id, params?}. Example:
        [{"paragraph_id": "p1"}, {"paragraph_id": "p2", "params": {"city": "Seoul"}}]
    params: Optional shared dynamic form values applied to every item, e.g. {"env": "prod"}.
        Per-item params override these per key.
    max_rows: Maximum data rows per table output (default 50, 0 = unlimited). Header row always included.
    include_html: If True, include HTML output converted to plain text. Default False.
    stop_on_error: If True (default), stop at the first paragraph that errors and report the
        remaining ones as skipped. If False, run every paragraph regardless of failures.

Input Schema

NameRequiredDescriptionDefault
runsYes
paramsNo
max_rowsNo
notebook_idYes
include_htmlNo
stop_on_errorNo

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.4.1

TDQS

A4.7/5.0
Behavior4/5

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

Annotations declare readOnly=false, idempotent=false, destructive=false; the description goes further, explaining sequential (not parallel) execution because cells share interpreter state, that N round-trips collapse to one, and how stop_on_error reports remaining paragraphs as skipped. It adds real value, but doesn't explain output size characteristics or what happens to already-run cells on failure.

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?

Purpose, usage, and execution semantics are front-loaded, and the Args block is consistently structured. Slight redundancy: the token-saving defaults are stated in prose and then repeated verbatim in the Args section, which costs a few lines.

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 six-parameter batch tool with no schema descriptions, the description supplies execution order, merge precedence, output truncation defaults, and error-handling policy. An output schema exists, so return-value detail is correctly not required.

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 description coverage is 0%, so the description must carry the full burden, and it does — every one of the six parameters is explained: runs with an inline example, the shared-vs-per-item params merge rule with precedence, repeatable paragraph_id for parameter sweeps, max_rows with 0=unlimited and header-row behavior, include_html, and stop_on_error defaults.

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?

States a specific verb and resource ('Run several paragraphs one after another in the given order, in a single call') and immediately contrasts with the sibling 'run_paragraph'. An agent can distinguish it from run_paragraph, run_all_paragraphs, and run_paragraph_async without opening the schema.

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?

Explicitly names the alternative it replaces ('instead of many run_paragraph calls') and the condition that selects it ('when you need a specific sequence of cells run — e.g. setup cells before the cells that depend on them'). The ordering rationale is spelled out rather than inferred.

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