Apache Zeppelin MCP Server

update_paragraph_config

Idempotent

Updates a Zeppelin paragraph's chart and display settings by deep-merging config changes, including graph type, columns, and auto-filled output fields.

Instructions

Update paragraph visualization/chart config (graph type, columns, display settings). Fetches current config and deep-merges provided changes. Column index and aggr fields are auto-filled from the paragraph's output headers — only provide name. Auto-fill needs saved output: run the paragraph at least once first, otherwise index/aggr cannot be auto-filled and columns are passed through as given.

Args:
    notebook_id: The notebook ID containing the paragraph
    paragraph_id: The paragraph ID to configure
    config: Dict of config fields to set or update. Merged with existing config.
        To change chart type, set graph.mode to one of:
        "table", "multiBarChart", "stackedAreaChart", "lineChart",
        "pieChart", "scatterChart".
        Example: {"graph": {"mode": "multiBarChart",
                            "keys": [{"name": "date_col"}],
                            "values": [{"name": "amount_col"}]}}

Input Schema

Name	Required	Description	Default
`config`	Yes
`notebook_id`	Yes
`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.3/5.0

Behavior4/5

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

Annotations declare idempotentHint=true and destructiveHint=false, and the description genuinely adds beyond that: it discloses that changes are deep-merged into the existing config rather than replacing it, and that columns are passed through unchanged when no saved output exists. Missing only permission/authorization context and failure modes.

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?

Front-loads purpose, then merge semantics, then the auto-fill caveat, then a structured Args block with an example. Slightly verbose in the auto-fill explanation but every sentence carries actionable information; nothing is filler.

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?

An output schema exists so return values needn't be described. Given a nested free-form config object, the description supplies the merge model, the accepted enum values, an example payload, and the output-dependency prerequisite — everything needed to call it correctly on the first try.

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 carries the full burden and does: it explains each of the three params in an Args block, clarifies that only 'name' is needed for column entries because index/aggr are auto-filled, and enumerates the valid graph.mode values plus a worked example for the free-form config object.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

Opens with a specific verb and resource: 'Update paragraph visualization/chart config (graph type, columns, display settings)'. An agent can distinguish it from update_paragraph or update_paragraph_forms, though it never explicitly names those siblings to route away from them.

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?

Gives a concrete prerequisite: the paragraph must have saved output from a prior run, otherwise index/aggr auto-fill cannot happen — which implicitly routes the agent to run_paragraph first. It does not mention the batch sibling (batch_update_paragraph_config) as an alternative for multi-paragraph edits.

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