Kafka MCP Server is an MCP server implementation for Apache Kafka, whose goal is to enable large language models (LLMs) to interact with and manage Kafka clusters.
Main purpose and positioning: As an MCP server, it exposes common operational and management operations of Kafka clusters to LLMs, enabling the model to view clusters, operate topics, manage consumer groups, and send and receive messages in the form of controlled tool calls.
Main capabilities:
- Cluster management: View broker details through describe_cluster and describe_brokers.
- Topic management: Supports list_topics (list), create_topic (create), delete_topic (delete), describe_topic (view), and create_partitions (add partitions).
- Configuration management: View configurations through describe_configs, and modify the dynamic configurations of topics, brokers, and groups through alter_configs.
- Consumer groups: list_consumer_groups (list), describe_consumer_group (view), and safely manage offsets through reset_consumer_group_offset and rewind_consumer_group_offset_by_timestamp; advanced tools include status validation, dry run, and execution audit logs.
- Message sending and receiving: consume_messages can consume messages from the beginning, latest, or a specified offset, and produce_message can produce messages.
- Secure connections: Supports TLS/mTLS, as well as SASL mechanisms such as PLAIN, SCRAM-SHA-256, SCRAM-SHA-512, GSSAPI, and OAUTHBEARER.
- JMX monitoring: Can read broker and topic metrics from one or more Prometheus JMX Exporter endpoints, and aggregate cluster health status.
How to use: Requires the uv package manager (recommended) and a running Kafka cluster (for example, local Docker, Confluent Cloud, etc.). First clone the repository, then install dependencies through uv sync. Among the configuration items, only KAFKA_BOOTSTRAP_SERVERS is required, and the existing PLAINTEXT configuration remains unchanged. When using SASL security protocols, KAFKA_SASL_MECHANISM needs to be set to PLAIN, SCRAM-SHA-256, SCRAM-SHA-512, GSSAPI, or OAUTHBEARER. The server can be run directly with uv or python, or Docker can be used; the Docker image supports TLS, PLAIN, SCRAM, OAUTHBEARER/OIDC, and GSSAPI, and its multi-stage build compiles the Python client based on a checksum-verified librdkafka release with Kerberos support. Example of running the container: docker run -i --rm -e KAFKA_BOOTSTRAP_SERVERS=host.docker.internal:9092 kafka-mcp (if the Kafka cluster is running on the host machine, use host.docker.internal instead of localhost). The Claude Desktop configuration requires adding the corresponding content in claude_desktop_config.json.
Applicable scenarios: Scenarios that require performing tasks such as viewing and managing Kafka clusters, adjusting consumer group offsets, and consuming and producing messages in an LLM or MCP client environment; it can also be used to read JMX metrics and aggregate cluster health status.
Limitations and notes: For the GSSAPI/Kerberos part, prebuilt confluent-kafka wheels do not include GSSAPI, and Kerberos deployments outside Docker need to install confluent-kafka against a librdkafka build with SASL GSSAPI support; the provided Docker image builds this variant from source and includes Kerberos runtime tools. In OAUTHBEARER, KAFKA_SASL_OAUTHBEARER_EXTENSIONS is optional; librdkafka's default unsecured-token handler is only usedfor development and testing. JMX monitoring is optional and does not affect the Kafka tools; Prometheus JMX Exporter needs to be run as a Java agent on each broker and its HTTP /metrics endpoint provided. It is recommended to keep Java RMI disabled to avoid exposing Kafka's unauthenticated remote JMX port; when the exporter endpoint is not set, the JMX tool returns a structured not_configured response. Other details (such as the complete list of available tools, project structure, etc.) are described separately in the official documentation.
