kafka-sentinel-mcp
kafka-sentinel-mcp is a read-only MCP server that gives AI agents safe, structured visibility into Kafka clusters for diagnosing streaming incidents—without any write, produce, config mutation, or admin access.
list_topics: Discover all non-internal topics with partition count and replication factor.list_consumer_groups: List all consumer group IDs and their state.cluster_health: Report broker count, controller status, and under-replicated/offline partition counts.consumer_lag: Show per-group, per-topic, per-partition lag (committed offset = -1 means no stored offset).topic_audit: Audit replication factor,min.insync.replicas, and retention—flagging configs that violate durability best practices.partition_state: Reveal leaders, ISR state, and leader skew across brokers per partition.replay_readiness: Check whether earliest available offsets still cover the gap since committed offsets, or if retention has deleted the data.incident_snapshot: Return a single timestamped bundle of health + lag + audit + partition state + replay readiness, ideal for postmortems.
All tools are strictly read-only by construction, return structured results on ACL failures (never stack traces), support SASL/SSL, log every call, and never log credentials.
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., "@kafka-sentinel-mcpCheck consumer lag for payments group"
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.
kafka-sentinel-mcp
Give AI agents safe, read-only eyes on your Kafka clusters.
An MCP (Model Context Protocol) server that exposes Kafka cluster health, consumer lag, partition state, and replay-readiness as structured tools — so LLM agents (Claude, or any MCP client) can diagnose streaming incidents without ever being able to break anything.
Built by an engineer who spent a decade running Kafka-based financial messaging at 99.999% availability, and got tired of every "AI + Kafka" demo assuming write access to production.
Why this exists
When a consumer group stalls at 3 a.m., the questions are always the same: Is it lag? A stuck partition? A rebalance storm? An offset reset gone wrong? These are pattern-matching questions — exactly what LLM agents are good at — but no operator will hand an agent admin rights on a production cluster.
kafka-sentinel-mcp draws a hard line: every tool is read-only by design, enforced at the client-config level (no admin operations are even imported). The agent can observe, correlate, and recommend; a human executes.
Related MCP server: MCP Kafka
Tools
Tool | What it returns |
| All non-internal topics with partition count and replication factor — start here if you don't know a topic name |
| All consumer group IDs with state — start here if you don't know a group name |
| Broker count, controller status, under-replicated / offline partition counts |
| Per-group, per-topic, per-partition lag with committed vs end offsets |
| Replication factor, min.insync.replicas, retention, and flags configs that violate durability best practice |
| Leaders, ISR shrinkage, skew across brokers |
| For a group + topic: earliest available offsets vs committed, i.e., "can we still replay what we missed?" |
| One-call bundle of all the above, timestamped — designed for pasting into a postmortem |
Quick start
pip install kafka-sentinel-mcp # (or: uv tool install)
# Run against your cluster (read-only credentials!)
KAFKA_BOOTSTRAP=localhost:9092 kafka-sentinel-mcpAdd to Claude Desktop / any MCP client:
{
"mcpServers": {
"kafka-sentinel": {
"command": "kafka-sentinel-mcp",
"env": { "KAFKA_BOOTSTRAP": "broker1:9092,broker2:9092" }
}
}
}Then ask your agent: "Why is the payments-consumer group falling behind, and can we still replay from where it stalled?"
Security posture
Read-only by construction: no produce, no topic/config mutation, no offset commits, no ACL ops. The mutation APIs are never imported, and a test in CI greps the server source on every run to keep it that way.
The observer consumer runs with
enable.auto.commit=Falseand never commits — verified against a real broker, not just asserted.Supports SASL/SSL; credentials are read from the environment only and never logged.
Every tool call is logged with its parameters for audit.
Least privilege: run with a principal that has only
Describeon the cluster and topics, andDescribeon consumer groups. When an ACL denies an operation the tool returns a structured result rather than a stack trace:{ "error": "permission_denied", "operation": "list_consumer_groups", "detail": "...", "hint": "The Kafka principal in use lacks the ACL required for this operation. ..." }The agent can then tell the operator which ACL is missing instead of appearing broken. Non-authorization failures are deliberately not swallowed — they propagate, because silently degrading on an unrelated error would hide real problems.
Testing
pip install -e ".[dev]"
pytest -m "not integration" # fast, fully mocked — no Docker needed
pytest -m integration # starts a real Kafka via testcontainers (needs Docker)
pytest # bothThe unit suite mocks librdkafka entirely and covers tool logic. The integration suite starts an actual broker, produces real records, and asserts the tools return correct lag, ISR state, durability flags, and replay-readiness — including that the observer leaves no committed offsets behind. Both run in CI.
Status
Early but tested. See ROADMAP.md. Issues and PRs welcome — especially war stories about what you wish an agent could have told you during an incident.
Citing this work
If you reference this project in academic work, see CITATION.cff, or use the "Cite this repository" button on GitHub.
License
MIT
Maintenance
Resources
Unclaimed servers have limited discoverability.
Looking for Admin?
If you are the server author, to access and configure the admin panel.
Related MCP Servers
- AlicenseBqualityCmaintenanceMCP server for Apache Kafka that allows LLM agents to inspect topics, consumer groups, and safely manage offsets (reset, rewind).1612Apache 2.0
- Alicense-qualityAmaintenanceAn MCP server that enables AI assistants to safely interact with Apache Kafka clusters, providing tools for topic management, message operations, consumer groups, and cluster information.3MIT
- Alicense-qualityDmaintenanceAn MCP server that gives AI agents real-time observability into Apache Kafka clusters, enabling natural language queries for broker health, consumer lag, and diagnostics.MIT
- AlicenseAqualityCmaintenanceA read-only MCP server for inspecting Kubernetes clusters, allowing LLMs to list resources, describe pods, and read logs without mutation.5MIT
Related MCP Connectors
Read-only Remote MCP for externally grounded AI agent trust receipts.
Read-only MCP server for wafergraph.com's semiconductor & AI supply-chain data: 30 tools, no auth.
MCP server for AI agents to plan, verify, and deploy Cloudflare-native apps.
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
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/sanjay-amu/kafka-sentinel-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server