Apache Zeppelin MCP Server

get_paragraph

Read-onlyIdempotent

Retrieves full content of an Apache Zeppelin notebook paragraph, including code, output, dynamic forms, chart settings, and presentation flags, with optional row limits and HTML text extraction.

Instructions

Get full content of a single paragraph (code, output, dynamic forms, chart config, and presentation flags like editorHide / runOnSelectionChange).

By default, table output is limited to 50 rows and HTML output is omitted to save tokens.
When investigating data discrepancies, set max_rows=0 for unlimited rows.
If the paragraph uses HTML rendering (without z.show()), set include_html=True to see
text extracted from HTML. Alternatively, query the underlying data via SQL if available.

Args:
    notebook_id: The notebook ID containing the paragraph
    paragraph_id: The paragraph ID to retrieve
    max_rows: Maximum data rows for table output (default 50, 0 = unlimited). Header row always included.
    include_html: If True, include HTML output converted to plain text. If False (default), HTML is omitted.

Input Schema

Name	Required	Description	Default
`max_rows`	No
`notebook_id`	Yes
`include_html`	No
`paragraph_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.6/5.0

Behavior4/5

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

Annotations already declare readOnly, idempotent, and non-destructive behavior. The description adds meaningful beyond-annotation context: default truncation of table output to 50 rows, omission of HTML by default to save tokens, and the guarantee that the header row is always included.

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 key behavior and token-saving defaults are front-loaded, followed by actionable guidance and a clean args list. Every sentence adds practical value with no 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 that an output schema exists and annotations cover the safety profile, the description is complete: it explains what content is returned, the default truncation behavior, and how to adjust parameters for fuller output.

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?

With 0% schema description coverage, the description fully compensates by documenting all four parameters, including defaults (max_rows=50, include_html=False) and the special semantics of max_rows=0 meaning unlimited.

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 names a specific verb and resource ('Get full content of a single paragraph') and enumerates what is included (code, output, dynamic forms, chart config, presentation flags), which distinguishes it from partial-content siblings like get_paragraph_code and get_paragraph_forms.

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?

It gives concrete situational guidance: set max_rows=0 when investigating data discrepancies, and include_html=True when the paragraph uses HTML rendering, plus a SQL alternative. It does not explicitly route between this tool and the content-specific siblings such as get_paragraph_code, so it is clear but not fully exhaustive on alternatives.

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