Skip to main content
Glama

🦊 kafka-mcp

An MCP server that gives your AI agents eyes into Apache Kafka.

kafka-mcp exposes Kafka administration operations as Model Context Protocol tools, so assistants like Claude Desktop, Claude Code, or any MCP-compatible client can inspect and operate your cluster in plain language — "list all my topics with their replication factor" — instead of you reaching for the CLI.

It ships with a batteries-included docker-compose.yml that spins up a complete local Kafka lab (KRaft broker + Schema Registry + Web UI) so you can try it end-to-end in minutes.


✨ Features

  • 🔌 Drop-in MCP server — runs over stdio, so any MCP client can launch it as a subprocess.

  • 📋 Topic management — list & describe topics, create / delete, add partitions, and read or alter configs.

  • 👥 Consumer group insight — list & describe groups, inspect members & assignments, and compute per-partition lag.

  • 📨 Produce & peek — send a message to a topic, or read recent records back without committing offsets.

  • 🩺 Cluster & offset views — describe brokers / controller and fetch earliest / latest watermarks per partition.

  • Async-friendly — blocking Kafka admin calls are offloaded to worker threads so the event loop stays snappy.

  • 🐳 Self-contained local lab — one docker compose up gives you Kafka (KRaft, no ZooKeeper), Schema Registry, and a Web UI.

  • 🛠️ Tiny & hackable — a single module (src/zaksway_kafka_mcp/__init__.py) you can read in one sitting and extend with new tools.


Related MCP server: Kafka MCP Server

🧭 How it works

┌──────────────────┐   MCP over stdio   ┌──────────────────┐   Kafka Admin API   ┌──────────────────┐
│   AI Agent       │ ◀───────────────▶  │   kafka-mcp      │ ◀────────────────▶  │   Kafka broker   │
│ (Claude, etc.)   │   tool calls       │  (FastMCP server)│   confluent-kafka   │  (localhost:9092)│
└──────────────────┘                    └──────────────────┘                     └──────────────────┘

The agent never talks to Kafka directly — it calls a tool, kafka-mcp translates that into a confluent-kafka admin or client request, and returns structured JSON the model can reason about.


📦 Prerequisites

  • Python 3.12+

  • uv for dependency management (recommended)

  • Docker + Docker Compose (only if you want the local Kafka lab)


🚀 Quick start

1. Clone & install

git clone <your-repo-url> kafka-mcp
cd kafka-mcp
uv sync

2. Start a local Kafka (optional, but handy)

docker compose up -d

This brings up three services:

Service

URL / Port

What it's for

Kafka broker

localhost:9092

The broker your MCP server connects to

Schema Registry

http://localhost:8081

Avro/Protobuf/JSON schema management

Kafka UI

http://localhost:8080

Browse topics, messages, and consumer groups

💡 Auto-create topics is enabled, so you can produce to a new topic and watch it appear via the MCP list_topics tool.

3. Run the MCP server

uv run kafka-zaksway

You should see:

Kafka MCP for you agents!

The server is now listening on stdio, ready for an MCP client to connect.


🤖 Connecting an MCP client

Most clients (Claude Desktop, Claude Code, …) launch MCP servers from a JSON config. Once it's installed from PyPI, point them at the published package — no clone required:

{
  "mcpServers": {
    "kafka-zaksway": {
      "command": "uvx",
      "args": ["zaksway-kafka-mcp"],
      "env": {
        "BOOTSTRAP_SERVER": "localhost:9092"
      }
    }
  }
}
  • Claude Desktop → add the block to claude_desktop_config.json.

  • Claude Codeclaude mcp add kafka-zaksway -- uvx zaksway-kafka-mcp

💡 Hacking on a local clone instead? Swap to "command": "uv" with "args": ["--directory", "/absolute/path/to/zaksway-kafka-mcp", "run", "kafka-zaksway"].

Restart the client, and kafka-zaksway will appear among your available tools.


🧰 Available tools

kafka-mcp exposes 14 tools spanning topic management, consumer groups, the cluster, and the data plane. Tools marked ⚠️ are destructive (they delete data) — agents should confirm before calling them.

Category

Tool

Parameters

Description

Topics

list_topics

withInternal: bool

List topics with partition count & replication factor.

Topics

describe_topic

topic: str

Per-partition leader / replicas / ISR + non-default config overrides.

Topics

create_topic

topic: str, partitions: int = 1, replication_factor: int = 1, config: dict = {}

Create a new topic.

Topics

delete_topic ⚠️

topic: str

Permanently delete a topic and all of its data.

Topics

add_partitions

topic: str, new_total_count: int

Increase a topic's partition count (cannot shrink).

Topics

alter_topic_config

topic: str, config: dict

Set / update topic configuration entries.

Topics

get_topic_offsets

topic: str

Earliest & latest offsets (watermarks) per partition.

Cluster

describe_cluster

Cluster id, controller broker, and broker list.

Groups

list_consumer_groups

All consumer groups with their state.

Groups

describe_consumer_group

group_id: str

State, coordinator, members & their partition assignments.

Groups

consumer_group_lag

group_id: str

Committed offset, end offset, and lag per partition.

Groups

delete_consumer_group ⚠️

group_id: str

Permanently delete a consumer group.

Data

produce_message

topic: str, value: str, key: str = null, partition: int = null

Produce a single message and await delivery.

Data

consume_messages

topic: str, max_messages: int = 10, timeout_seconds: float = 5.0, from_beginning: bool = true

Peek recent messages without committing offsets.

💡 The registered MCP tool names are full descriptive sentences (e.g. Show committed offsets and lag for a Kafka consumer group); the short identifiers above mirror the Python functions in src/zaksway_kafka_mcp/__init__.py and are used here for brevity.

Example — list_topics response:

[
  { "name": "orders",   "partitions": 6, "replication-factor": 1 },
  { "name": "payments", "partitions": 3, "replication-factor": 1 }
]

⚙️ Configuration

The server is configured entirely through environment variables.

Variable

Default

Description

BOOTSTRAP_SERVER

localhost:9092

Kafka bootstrap server(s) to connect to.


📦 Releasing to PyPI

The package is published to PyPI as zaksway-kafka-mcp by a GitHub Actions workflow (.github/workflows/publish.yml) that triggers on v* version tags and authenticates via Trusted Publishing (OIDC) — no API tokens stored anywhere.

One-time setup — register a Trusted Publisher on PyPI:

Field

Value

Owner

zakariahere

Repository

zaksway-kafka-mcp

Workflow filename

publish.yml

Environment

pypi

To cut a release:

# 1. Bump `version` in pyproject.toml (e.g. 0.1.0 -> 0.2.0), then:
git commit -am "release: v0.2.0"
git tag v0.2.0
git push origin master --tags

The workflow verifies the tag matches pyproject.toml, builds the wheel + sdist, smoke-tests both, and publishes. Once published, anyone can run it with zero install:

uvx zaksway-kafka-mcp           # run the server directly
# or
pip install zaksway-kafka-mcp   # then run: kafka-zaksway

🗂️ Project structure

kafka-mcp/
├── src/zaksway_kafka_mcp/
│   ├── __init__.py     # The MCP server + all 14 tool definitions
│   └── __main__.py     # `python -m zaksway_kafka_mcp` entry point
├── tests/
│   └── smoke_test.py   # Import/packaging check run in CI before publish
├── .github/workflows/
│   └── publish.yml     # Build + publish to PyPI on `v*` tags (Trusted Publishing)
├── docker-compose.yml  # Local Kafka lab (broker + schema registry + UI)
├── pyproject.toml      # Project metadata, dependencies & build backend
├── uv.lock             # Pinned dependency lockfile
└── README.md           # You are here

🛣️ Roadmap

Recently shipped ✅

  • create_topic / delete_topic

  • add_partitions & alter_topic_config

  • Describe consumer groups & their lag

  • Peek at the latest messages on a topic

Ideas for what's next:

  • Reset / set consumer group offsets

  • ACL management (list / create / delete)

  • Broker config inspection

  • Schema Registry integration (list subjects & schemas)


🧑‍💻 Author

Zakaria BOUAZZA : https://zakaria.lu

📄 License

No license has been specified yet. Add one (e.g. MIT) before sharing publicly.

Available Tools

1 tool
List all non internal topics with their partition number and replication factorC

List Kafka topics with partition count and replication factor.

ParametersJSON Schema
NameRequiredDescriptionDefault
withInternalYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

C2.4/5.0
Behavior2/5

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

No annotations are provided, so the description carries full burden for behavioral disclosure. It only states the basic action without revealing important traits like whether the list is exhaustive, pagination, permissions required, or impact on the system.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is very short (one sentence), which is concise but lacks critical details. It could be expanded with essential information without becoming overly verbose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the presence of an output schema, the description does not need to explain return values, but it fails to compensate for the 0% parameter description coverage. The description omits the parameter's meaning and default behavior, making it incomplete for effective tool use.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, but the description does not explain the 'withInternal' parameter. The parameter's purpose is only hinted by its name, leaving ambiguity about its effect (e.g., whether it includes or excludes internal topics).

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?

The description clearly states it lists Kafka topics with partition count and replication factor, which matches the tool name. However, it fails to mention the default exclusion of internal topics or explain the role of the 'withInternal' parameter.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

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, and no sibling tools are provided for context. The description does not indicate prerequisites, typical use cases, or limitations.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. 1 tool updatev0.1.0
    • First observedList all non internal topics with their partition number and replication factor

TDQS

C2.5/5.0
Disambiguation5/5

With only one tool, there is no risk of confusion between tools. The single tool's purpose is clear and unambiguous.

Naming Consistency3/5

There is only one tool, so no inconsistency exists. However, its name is a full sentence rather than a concise verb_noun pattern, which is atypical for MCP tool naming.

Tool Count2/5

A single tool for a Kafka server is insufficient. Kafka has a rich API requiring multiple operations; one tool suggests minimal functionality.

Completeness1/5

Only listing topics is available. Missing essential operations like creating, deleting, producing/consuming messages, managing consumer groups, etc. The tool surface is severely incomplete for a Kafka server.

Maintenance

ActivityInactive
ResponsivenessNo issues

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Related MCP Servers

  • A
    license
    Not graded
    quality
    C
    maintenance
    Enables AI agents to interact with Apache Kafka through natural language, supporting operations like producing/consuming messages, managing topics, and querying brokers, partitions, and consumer group offsets.
    1
    MIT
  • A
    license
    Not graded
    quality
    D
    maintenance
    An MCP server that enables interaction with Kafka clusters to manage topics, monitor consumer groups, and stream messages. It provides a comprehensive suite of tools for broker metadata inspection and local Kafka user management.
    MIT
  • A
    license
    B
    quality
    B
    maintenance
    MCP server for Apache Kafka that allows LLM agents to inspect topics, consumer groups, and safely manage offsets (reset, rewind).
    19
    13
    Apache 2.0
  • A
    license
    Not graded
    quality
    D
    maintenance
    Enables interaction with Kafka clusters via MCP, supporting topic management (list, create, delete, inspect), connection initialization, and more through natural language.
    1
    Apache 2.0

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/zakariahere/zaksway-kafka-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server