Provides tools for interacting with Apache Zeppelin's REST API, enabling AI agents to manage notebooks, paragraphs, interpreters, and execute data engineering workflows.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@zeppelin-mcp list all notebooks"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
MCP (Model Context Protocol) server for Apache Zeppelin. Gives Claude Code direct access to the Zeppelin REST API for AI-assisted data engineering workflows.
npm install -g @mihnea.dev/zeppelin-mcpRelated MCP server: Apache Airflow MCP Server
Add to ~/.claude.json:
{
"mcpServers": {
"zeppelin": {
"command": "zeppelin-mcp",
"env": {
"ZEPPELIN_URL": "https://your-zeppelin-instance",
"SOCKS5_PROXY": ""
}
}
}
}Or run directly with npx (no install needed):
{
"mcpServers": {
"zeppelin": {
"command": "npx",
"args": ["-y", "@mihnea.dev/zeppelin-mcp"],
"env": {
"ZEPPELIN_URL": "https://your-zeppelin-instance",
"SOCKS5_PROXY": ""
}
}
}
}ZEPPELIN_URL (required) — Base URL of the Zeppelin instance
SOCKS5_PROXY (optional) — SOCKS5 proxy address for tunneled access
Tool | Description |
| Authenticate with username/password |
| List all notebooks (IDs + paths) |
| Get notebook with all paragraphs |
| Create a new notebook |
| Delete a notebook |
| Read paragraph text and output |
| Write/modify paragraph text |
| Add a new paragraph |
| Remove a paragraph |
| Execute a paragraph, return output |
| Execute all paragraphs in a notebook |
| Restart an interpreter (spark, python, etc.) |
git clone https://github.com/mihneamanolache/zeppelin-mcp
cd zeppelin-mcp
npm install
npm run buildCreate a new notebook at the given path. Path uses '/' as folder separator (e.g. 'folder/notebook_name').
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Notebook path/name (e.g. 'my_folder/my_notebook') |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. The description only mentions creation and path format, but omits behavioral traits like overwrite behavior, required permissions, or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, front-loaded with the primary action. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequate for a simple one-param tool, but missing usage guidelines and behavioral transparency. Could include more context about file creation or overwrite behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%. The description adds the path separator detail, which is already implied in the schema's example. Minimal added value beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'Create a new notebook' and specifies the path format with '/'. It distinguishes from sibling tools like 'delete_notebook' and 'list_notebooks'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives such as 'get_notebook' or 'update_paragraph'. No prerequisites or exclusions mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add a new paragraph to a notebook. Optionally specify text and position index.
| Name | Required | Description | Default |
|---|---|---|---|
| text | No | The paragraph text (default: empty) | |
| index | No | Position to insert at (0-based). Omit to append at the end. | |
| notebookId | Yes | The notebook ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries the full burden. It states that the tool creates a new paragraph, which is non-destructive, but does not disclose potential side effects (e.g., shifting existing paragraphs when inserting at an index). The behavior is basic and implied, so a 3 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that covers the core action and optional parameters. Every word earns its place, with no waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple create tool with three parameters, the description is mostly complete. It could mention the return value or that inserting at an index shifts positions, but given the simplicity and schema richness, it is nearly sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already explains each parameter. The description adds 'Optionally specify text and position index', which merely restates the schema without adding new meaning. Baseline 3 is correct.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Add' and the resource 'paragraph to a notebook', making the purpose unambiguous. However, it does not explicitly differentiate from sibling tools like 'create_notebook' or 'run_paragraph', which reduces the score from perfect.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions optional parameters (text and position index) but provides no guidance on when to use this tool versus alternatives like 'update_paragraph' or 'delete_paragraph'. No when-not-to-use or context for selection is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete a notebook by ID. This action is irreversible.
| Name | Required | Description | Default |
|---|---|---|---|
| notebookId | Yes | The notebook ID to delete |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries full burden. It only mentions irreversibility but omits other behavioral traits like permission requirements, whether it's a hard delete, or any cascade effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no redundancy. Every word adds value: 'Delete a notebook by ID' states the action, 'This action is irreversible' adds critical warning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool with no output schema, the description is mostly adequate. However, it lacks information about return values or confirmation behavior, and could caution about dependencies.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for the single parameter. The description does not add meaning beyond the schema's 'The notebook ID to delete'. Baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (Delete) and the resource (notebook by ID). It distinguishes from sibling tools like create_notebook or get_notebook.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. While the irreversibility note is a warning, it does not help the agent decide between deletion and other operations like archiving or disabling.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Remove a paragraph from a notebook.
| Name | Required | Description | Default |
|---|---|---|---|
| notebookId | Yes | The notebook ID | |
| paragraphId | Yes | The paragraph ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description only says 'Remove,' implying deletion, but with no annotations provided, it lacks details on irreversibility, side effects, permissions, or return values.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is concise but lacks structure. It does not waste words, but it could be more informative without significant expansion.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple delete operation with two required parameters and no output schema, the description is minimally adequate. However, it does not explain return values or postconditions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the description does not add any meaning beyond the schema's parameter descriptions (notebookId, paragraphId). Baseline score applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Remove a paragraph from a notebook' clearly states the action and resource, distinguishing it from sibling tools like delete_notebook and update_paragraph.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives (e.g., when to delete vs. update a paragraph). No exclusions or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a notebook's structure: paragraph IDs, status, and first line of text. Use get_paragraph for full content of a specific paragraph.
| Name | Required | Description | Default |
|---|---|---|---|
| notebookId | Yes | The notebook ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden. It discloses the return structure (paragraph IDs, status, first line) and implies a read-only operation (get). While it could explicitly state non-destructive behavior, the description is adequate for a simple retrieval tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no wasted words. Front-loaded with the core purpose and immediately followed by usage guidance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one required parameter and no output schema, the description fully covers what the tool returns and how it relates to a sibling tool. No gaps are evident.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with one parameter 'notebookId' described as 'The notebook ID'. The description adds no extra meaning beyond the schema, so baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and the resource 'notebook's structure', specifying what is included (paragraph IDs, status, first line of text). It also distinguishes from the sibling tool 'get_paragraph' by noting that tool provides full content.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear guidance to use 'get_paragraph' for full content, implying this tool is for an overview. Lacks explicit when-not-to-use but effectively sets context for alternative tool usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read a single paragraph's text and output from a notebook.
| Name | Required | Description | Default |
|---|---|---|---|
| notebookId | Yes | The notebook ID | |
| paragraphId | Yes | The paragraph ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries full burden. It implies a safe read operation by stating 'read,' which is adequate but does not disclose authentication needs, error behavior, or idempotency. Provides minimal transparency beyond the action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, front-loaded, and contains no filler. It efficiently conveys the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (two straightforward parameters, no output schema), the description is adequate. It covers what the tool does without needing to detail return values, though it could mention that output refers to interpreter output.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds no extra meaning beyond the schema's parameter descriptions ('The notebook ID', 'The paragraph ID'). It does not clarify input formats or any constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool reads a single paragraph's text and output from a notebook. It uses a specific verb ('Read') and identifies the resource, distinguishing it from sibling tools like run_paragraph or update_paragraph.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. It does not mention that it is a read-only operation or that it lacks side effects, nor does it specify prerequisites or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List notebooks in Zeppelin. Use the query parameter to filter by path (case-insensitive substring match). Without a query, returns all notebooks (can be very large).
| Name | Required | Description | Default |
|---|---|---|---|
| query | No | Filter notebooks by path (case-insensitive substring match). Strongly recommended to avoid huge responses. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses behavior: returns all notebooks if no query, can be very large. No annotations present, so description carries full burden. Lacks details on returned data format or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no waste. Front-loaded with purpose and immediately provides actionable detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, so description should explain return format. It implies a list but doesn't specify fields. Could be more complete for an agent to invoke.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and description adds a warning ('Strongly recommended to avoid huge responses') that enhances the schema's description, providing practical usage guidance.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clear verb+resource: 'list notebooks in Zeppelin'. Distinguishes from sibling tools like create_notebook, delete_notebook, and get_notebook.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance to use query parameter for filtering and warns about potentially large responses. However, does not mention when to use alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Restart a Zeppelin interpreter by setting name (e.g. 'spark', 'python', 'sh', 'md'). Optionally scope to a specific notebook.
| Name | Required | Description | Default |
|---|---|---|---|
| notebookId | No | Optional notebook ID to scope the restart to a specific notebook | |
| interpreterName | Yes | Interpreter setting name (e.g. 'spark', 'python', 'sh', 'md') |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and the description does not disclose behavioral traits such as disruption to running paragraphs, permissions required, or whether the restart is global or scoped. Merely states the action without side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, front-loaded with the action, and includes essential details without fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple nature of the tool (restart action, 2 parameters, no output schema), the description covers the core functionality well. However, it lacks information about return values or confirmation behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, but the description adds value by providing example values for interpreterName and clarifying the optionality of notebookId. This goes beyond the schema's simple descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the action 'restart', the resource 'interpreter', and provides concrete examples like 'spark', 'python'. Distinguishes from sibling tools which focus on notebooks/paragraphs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool vs alternatives. Examples of interpreter names are given, but no context on prerequisites, consequences, or typical use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Execute all paragraphs in a notebook sequentially.
| Name | Required | Description | Default |
|---|---|---|---|
| notebookId | Yes | The notebook ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry full behavioral disclosure. It only states 'sequentially' but omits critical traits such as whether the execution is synchronous or asynchronous, error handling behavior, effect on notebook state, or return value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the action and resource. While there is no wasted text, it could benefit from slightly more structure, such as mentioning the outcome or alternatives.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of an output schema and the tool's action-oriented nature, the description lacks completeness. It does not explain what the agent can expect after execution (e.g., success indicator, paragraph results, or side effects like locking), leaving significant gaps for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The sole parameter 'notebookId' is fully described in the schema itself. The description adds no additional meaning beyond what the schema provides, so it meets the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Execute all paragraphs') and the resource ('in a notebook'), and adds 'sequentially' to specify the execution order. Among siblings, 'run_paragraph' targets a single paragraph, so the distinction is implicit, but the description does not explicitly contrast with it.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like 'run_paragraph' or 'stop_all_paragraphs'. There are no prerequisites, context, or exclusions mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Execute a single paragraph and return its output. This is a synchronous call that waits for execution to complete.
| Name | Required | Description | Default |
|---|---|---|---|
| notebookId | Yes | The notebook ID | |
| paragraphId | Yes | The paragraph ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
States synchronous and waiting behavior, but lacks details on idempotency, error handling, or side effects. Annotations absent so description carries burden.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise, front-loaded sentences with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Missing output schema and annotations; description does not cover return format or error scenarios, but tool is simple.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage 100% with clear parameter descriptions; description adds nothing beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clear verb 'Execute' and resource 'paragraph' with distinction from 'run_all_paragraphs' and 'stop_paragraph'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Mentions synchronous behavior but no explicit when-to-use or when-not-to-use vs siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Cancel all running paragraphs in a notebook.
| Name | Required | Description | Default |
|---|---|---|---|
| notebookId | Yes | The notebook ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It only states the action without mentioning side effects, permissions, or reversibility, leaving significant gaps for an agent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence efficiently conveys the core action, but the brevity sacrifices necessary detail for an agent to use the tool safely.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter, the description covers the basic action but lacks context on when to use it versus 'stop_paragraph' and behavioral caveats, leaving it somewhat incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a single parameter 'notebookId' described as 'The notebook ID'. The description adds no additional semantic value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Cancel' and the resource 'all running paragraphs in a notebook', distinguishing it from sibling 'stop_paragraph' which stops a single paragraph.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidance is provided: no mention of when to use this bulk operation versus individual stopping, no prerequisites or alternatives mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Cancel a running paragraph.
| Name | Required | Description | Default |
|---|---|---|---|
| notebookId | Yes | The notebook ID | |
| paragraphId | Yes | The paragraph ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description indicates the tool acts on a 'running' paragraph, implying a state requirement, but does not disclose side effects, idempotency, or error handling. With no annotations, the burden is on the description, yet it provides minimal behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no wasted words. It is appropriately sized for a simple tool, though it could benefit from slightly more detail without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool, the description is partially complete but lacks important details about behavior when the paragraph is not running, whether the action is reversible, and any required permissions or preconditions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and parameter names are self-explanatory. The description adds no additional meaning beyond what the schema already provides, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Cancel') and the resource ('a running paragraph'), and it distinguishes from siblings like 'run_paragraph' and 'stop_all_paragraphs'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like 'stop_all_paragraphs' or 'restart_interpreter'. Does not mention prerequisites or state constraints.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update a paragraph's text. Use this to write or modify code in a paragraph.
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | The new paragraph text (include interpreter directive like %pyspark on the first line) | |
| notebookId | Yes | The notebook ID | |
| paragraphId | Yes | The paragraph ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears full responsibility for behavioral disclosure. It only states that the tool updates text but omits details on side effects, required permissions, whether the update is immediate or queued, or any impact on paragraph execution state. The parameter description hints at interpreter directives, but this is not in the main description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences deliver the essential purpose without superfluous words. The description is front-loaded with the core action and directly states the use case.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple update tool with three required parameters and no output schema, the description covers the basic purpose and parameter hints. However, it lacks information about return values, error conditions, or the relationship to paragraph execution, which would help complete the context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers all parameters with descriptions (100% coverage), so the baseline is 3. The description adds minimal semantic value by suggesting the text is code, but does not elaborate on the role of IDs or provide examples. Overall adequate but not exceptional.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Update' and the resource 'paragraph text', and hints at the use case of writing/modifying code. However, it does not explicitly differentiate from sibling tools like create_paragraph or run_paragraph, which have overlapping purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as create_paragraph for new paragraphs or run_paragraph for execution. The description lacks any 'when to use' or 'when not to use' context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Authenticate with Apache Zeppelin using username and password. Must be called before any other tools. Stores session cookie for subsequent requests.
| Name | Required | Description | Default |
|---|---|---|---|
| password | Yes | Zeppelin password | |
| username | Yes | Zeppelin username |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses that it stores a session cookie for subsequent requests, which is a key behavioral trait beyond input schema. No annotations provided, so description carries full burden – adequately covers side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no waste, front-loaded with action. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple auth tool with no annotations and no output schema, the description covers purpose, prerequisite, and effect. Sibling tools are different enough that context is clear. Minor gap: no mention of error handling or token expiry.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% – both parameters are described. Description does not add extra meaning beyond what the schema provides, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the verb (authenticate), resource (Apache Zeppelin), and purpose. Distinguishes from sibling tools which are about notebook/paragraph operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states 'Must be called before any other tools' – clear guidance on when to use it. No alternatives or exclusions listed, but for an auth tool this is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Each tool has a clearly distinct purpose: notebook lifecycle, paragraph lifecycle, execution control, interpreter restart, and authentication. Descriptions clarify boundaries (e.g., get_notebook vs get_paragraph). No overlap or ambiguity.
All tools follow a consistent verb_noun pattern with underscores (e.g., create_notebook, delete_paragraph, run_all_paragraphs). The only slight deviation is zeppelin_login, but it still fits the pattern of action_resource. Naming is uniform and predictable.
14 tools provide a well-scoped surface for managing Zeppelin notebooks. It covers CRUD for notebooks and paragraphs, execution commands, interpreter restart, and authentication—neither too sparse nor excessive for the domain.
The toolset covers core notebook and paragraph operations, execution, and interpreter management. Minor gaps include no logout, no interpreter listing, and no notebook import/export, but the set is sufficient for typical agent interactions with Zeppelin.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
MCP server that lets AI assistants use all OneSchema features exposed via the public API.
Hosted MCP server connecting AI assistants to 9,000+ apps and 40,000+ actions via Zapier.
MCP server unifying ERPs, CRMs, APIs and knowledge base for Claude, ChatGPT and Gemini.
Unified MCP Server is a remote MCP connector for AI agents and vertical AI products that provides access to 22,000+ authorized SaaS tools across 400+ integrations and 24 categories directly inside LLMs (Claude, GPT, Gemini, Cohere). Tools operate only on explicitly authorized customer connections, enabling agents to safely read and write against live third-party systems.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/mihneamanolache/zeppelin-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
