|
| 1 | +# PCIP-6: Implement the MCP for Pulsar Admin Tool |
| 2 | + |
| 3 | +# Background knowledge |
| 4 | + |
| 5 | +Apache Pulsar is a cloud-native distributed messaging and streaming platform, offering unified messaging, storage, and stream processing. It features multi-tenancy, persistent storage, and seamless scalability. Pulsar provides a command-line tool `pulsar-admin` to manage clusters, tenants, namespaces, topics, and subscriptions. However, `pulsar-admin` requires users to learn a large number of CLI commands and options, which is not user-friendly for non-experts. |
| 6 | + |
| 7 | +Model Context Protocol (MCP) is an open standard that defines how external tools expose capabilities to large language models (LLMs) through structured tool schemas. MCP allows LLMs like GPT or Claude to interact with systems such as Pulsar through well-defined interfaces. This is analogous to USB-C as a standardized interface for hardware devices. |
| 8 | + |
| 9 | +# Motivation |
| 10 | + |
| 11 | +Although `pulsar-admin` provides comprehensive CLI access, it's not user-friendly for non-experts. Users often struggle to express complex management needs, such as "list all subscriptions with message backlog > 1000", using raw CLI syntax. |
| 12 | + |
| 13 | +This proposal aims to introduce a new module that exposes Pulsar Admin functionalities as MCP-compatible tools. This allows users to manage Pulsar clusters using natural language prompts, interpreted and executed by LLMs. |
| 14 | + |
| 15 | +Benefits include: |
| 16 | + |
| 17 | +- Simplified cluster operations using plain English or other natural languages |
| 18 | +- Multi-turn conversational interactions with context awareness |
| 19 | +- A clean, extensible tool layer that conforms to the `pulsar-java-contrib` architecture |
| 20 | + |
| 21 | + |
| 22 | +# Goals |
| 23 | + |
| 24 | +## In Scope |
| 25 | + |
| 26 | +- Implement a new module `pulsar-admin-mcp-contrib` to expose Pulsar admin functionalities via MCP protocol. |
| 27 | +- Support 70+ commonly used admin operations via structured MCP tools. |
| 28 | +- Provide built-in transport support for HTTP, STDIO, and SSE. |
| 29 | +- Implement robust context tracking and parameter validation. |
| 30 | +- Provide complete developer/user documentation and a demo use case. |
| 31 | + |
| 32 | +## Out of Scope |
| 33 | + |
| 34 | +- UI interfaces or web frontends (though it can be used as backend). |
| 35 | +- Pulsar core changes (only builds on `pulsar-java-contrib`). |
| 36 | +- Full support for all 120+ CLI commands (70+ are targeted for now). |
| 37 | + |
| 38 | +# High Level Design |
| 39 | + |
| 40 | +The system architecture consists of four main layers: |
| 41 | + |
| 42 | +1. **LLM Interface Layer**: Accepts natural language inputs from an LLM and generates MCP-compatible tool calls |
| 43 | +2. **Protocol Layer**: Central MCP interface that dispatches structured requests to tool handlers |
| 44 | +3. **Tool Execution Layer**: Looks up registered tools and invokes appropriate Pulsar Admin API operations |
| 45 | +4. **Context Management Layer**: Maintains session memory, allowing parameter inheritance across steps |
| 46 | + |
| 47 | +Example interaction: |
| 48 | + |
| 49 | +User input: |
| 50 | +> "Create a topic named `user-events` with 3 partitions" |
| 51 | +
|
| 52 | +LLMs send structured tool calls (as per MCP schema) such as: |
| 53 | +```json |
| 54 | +{ |
| 55 | + "tool": "create-topic", |
| 56 | + "parameters": { |
| 57 | + "name": "user-events", |
| 58 | + "partitions": 3 |
| 59 | + } |
| 60 | +} |
| 61 | +``` |
| 62 | + |
| 63 | +MCP executes the tool and returns a structured result, which the LLM then summarizes in natural language. |
| 64 | +# Detailed Design |
| 65 | + |
| 66 | +## Design & Implementation Details |
| 67 | + |
| 68 | +### Package structure: |
| 69 | +```java |
| 70 | +pulsar-java-contrib/ |
| 71 | + ├── MCPProtocol.java # MCP protocol interface |
| 72 | + ├── MCPFactory.java # Factory class for dynamically loading protocol instances |
| 73 | + ├── tools/ # Tool registration and concrete implementations |
| 74 | + ├── client/ # PulsarAdmin client management |
| 75 | + ├── context/ # Session state management |
| 76 | + ├── validation/ # Parameter validation mechanism |
| 77 | + ├── transport/ # Support for HTTP, STDIO,SSE |
| 78 | + ├── model/ # Data structures like ToolSchema, ToolResult, etc |
| 79 | +``` |
| 80 | + |
| 81 | +### Key components: |
| 82 | +- `PulsarAdminTool`: Abstract base class for all tools (e.g. list-topics, create-tenant) |
| 83 | +- `ToolExecutor`: Handles concurrency, thread pools, and context updates |
| 84 | +- `ToolRegistry`: Registers all tools via Java SPI |
| 85 | +- `SessionManager`: Tracks ongoing sessions and enhances parameters |
| 86 | +- `ParameterValidator`: Validates tool input against ToolSchema metadata |
| 87 | + |
| 88 | +### Supported tools |
| 89 | + |
| 90 | +**Total tools**: 70+ |
| 91 | +Grouped by category: |
| 92 | +- **Cluster**: list-clusters, create-cluster, get-cluster-stats |
| 93 | +- **Tenant**: list-tenants, create-tenant, delete-tenant |
| 94 | +- **Namespace**: create-namespace, set-retention-policy, list-namespaces |
| 95 | +- **Topic**: create-topic, delete-topic, list-topics, compact-topic, get-topic-stats |
| 96 | +- **Subscription**: reset-subscription, get-subscription-stats |
| 97 | +- **Message**: produce-message, peek-messages |
| 98 | +- **Schema**: upload-schema, check-schema-compatibility |
| 99 | +- **Monitoring**: get-cluster-performance, diagnose-topic |
| 100 | + |
| 101 | +Each tool includes: |
| 102 | + |
| 103 | +- A ToolSchema (for LLM prompt templates and validation) |
| 104 | +- A handler (e.g. `ListTopicsHandler`) |
| 105 | +- Parameter schema, default values, error messages |
| 106 | + |
0 commit comments