What wklee610/kafka-mcp MCP server does
The wklee610/kafka-mcp MCP server gives an MCP client access to Kafka cluster operations through a collection of structured tools. It can retrieve cluster and broker metadata, inspect and manage topics, view or change dynamic configurations, work with consumer groups, and send or read records.
Topic operations include listing, describing, creating, deleting, and increasing partition counts. Consumer-group tools cover discovery and inspection, along with offset reset and timestamp-based rewind operations. The offset-management tools include state validation, dry-run support, and execution audit logging, which are relevant when changing how a group resumes consumption.
The server also provides optional health summaries from Prometheus JMX Exporter endpoints. These metrics can cover replication, in-sync replicas, controller state, log directories, broker, and topic measurements, subject to the metrics exposed by the configured endpoints.
How it works
The wklee610/kafka-mcp MCP server runs locally with Python 3.10 or newer and communicates with an MCP client over its standard process interface. It uses KAFKA_BOOTSTRAP_SERVERS to locate the Kafka cluster, then creates a Kafka client using the supplied connection and authentication settings.
Run it with uv run kafka-mcp, or build and run the supplied Docker image. A client configuration can launch the process with an environment containing the bootstrap broker address. The repository documents a Claude Desktop setup using uv and the project directory.
Kafka tools do not require JMX monitoring. JMX functionality is enabled separately by supplying one or more HTTP /metrics endpoints from Prometheus JMX Exporter. Endpoints can be provided as JSON, a URL list, or named URL entries. Requests can use HTTPS, custom CA material, client certificates, HTTP Basic authentication, or bearer authentication.
Setup and configuration
Install Python 3.10 or newer, clone the repository, and install dependencies with uv sync. A running Kafka cluster is required. The only required setting is KAFKA_BOOTSTRAP_SERVERS, containing comma-separated broker addresses such as localhost:9092; the default client ID is kafka-mcp.
Optional connection settings select PLAINTEXT, SSL, SASL_PLAINTEXT, or SASL_SSL. SASL supports PLAIN, SCRAM-SHA-256, SCRAM-SHA-512, GSSAPI, and OAUTHBEARER. TLS settings accept CA, client certificate, private key, key password, hostname verification, and certificate revocation list paths. Additional scalar librdkafka properties can be passed as a JSON object through KAFKA_CLIENT_CONFIG_JSON.
Kerberos requires a librdkafka build with GSSAPI support; the documented Docker image builds that variant. OAUTHBEARER can use librdkafka OIDC, metadata, or client-assertion flows, with flow-specific settings.
Tools and capabilities
The wklee610/kafka-mcp MCP server includes tools for:
- Describing the cluster and listing brokers.
- Listing, creating, deleting, describing, and repartitioning topics.
- Reading and changing dynamic topic, broker, and group configurations.
- Listing and describing consumer groups.
- Resetting offsets or rewinding them by timestamp, with validation and dry-run behavior.
- Consuming messages from the beginning, latest position, or specified offsets.
- Producing messages to Kafka.
- Summarizing broker and topic health from configured JMX Exporter endpoints.
Limitations and notes
The server does not include a built-in Kafka cluster; it must connect to an existing deployment. JMX tools return a structured not_configured result when no exporter endpoints are supplied. Client certificates and private keys must be configured together for mTLS.
The prebuilt confluent-kafka wheels do not provide GSSAPI. Deployments using Kerberos outside Docker need a compatible librdkafka build. The README also cautions that librdkafka’s unsecured OAuth bearer token handler is intended only for development and testing.