Apache Zeppelin MCP Server

batch_add_paragraph

Add multiple paragraphs to a Zeppelin notebook in one sequential batch call, reducing repeated round-trips while reporting any item failures.

Instructions

Add multiple paragraphs to a notebook in one call (batch version of add_paragraph). Paragraphs are created sequentially in the given order.

Prefer this over many add_paragraph calls when scaffolding several cells — it collapses N
round-trips into one. One failing item does not stop the rest (failures are reported).

Args:
    notebook_id: The notebook ID to add paragraphs to
    paragraphs: List of paragraphs to create, each {text, title?, index?}.

Input Schema

Name	Required	Description	Default
`paragraphs`	Yes
`notebook_id`	Yes

Output Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.4.1Oct 26, 2026

TDQS

A4.9/5.0

Behavior5/5

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

The annotations already establish that this is a non-read-only, non-idempotent, non-destructive mutation. The description adds important behavior beyond annotations: paragraphs are created sequentially in the given order, and one failing item does not stop the rest, with failures reported.

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 front-loaded with the core purpose and batch behavior, then supplies the key usage preference and partial-failure semantics. The Args block is compact and no sentence is 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 two-parameter batch mutation tool, the description covers purpose, usage preference, sequencing, partial failure behavior, and parameter structure. An output schema exists, so return-value details need not be repeated in the description.

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 needs to carry parameter meaning. It lists both top-level parameters and the nested paragraph fields {text, title?, index?}, which compensates well for the schema gap. However, it does not explain the semantics of index or how ordering interacts with it, leaving a minor gap.

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 verb and resource: adding multiple paragraphs to a notebook in one call. It explicitly identifies itself as the batch version of add_paragraph and distinguishes that from the sibling single-item tool.

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?

It gives an explicit usage condition: prefer this over many add_paragraph calls when scaffolding several cells because it collapses N round-trips into one. The alternative tool is named directly, so the agent knows when to choose this versus add_paragraph.

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