What can you do with this server?

This MCP server lets you monitor and manage Apache Kafka clusters, with read-only, read-write, and admin modes controlled by flags. * Monitor Kafka clusters: view cluster info, brokers, controller, and cluster id. * Inspect topics: list topics (optionally including internal ones), describe partitions/replicas/configs, and view earliest/latest offsets. * Track consumer groups: list consumer groups and describe group state with per-partition and total consumer lag. * Manage topics and groups (read-write mode): create topics, add partitions, alter topic configs, and reset consumer group offsets. * Delete resources (admin mode + delete flag): delete topics and consumer groups. * Stay safe by default: starts read-only, supports topic allowlists, protects internal/critical topics, dry-run mode, and audit logging.

Which integrations are available for this server?

Provides monitoring and management for Apache Kafka clusters, including cluster/topic metadata, consumer groups and lag, topic creation and configuration, partition management, offset resets, and guarded deletion of topics and consumer groups.

How do I use mcp-kafka?

1. Click on "Deploy Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@mcp-kafka Which consumer groups have the most lag right now?" 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.

de en es ja ko ru zh

mcp-kafka

by dockndevai

Overview Schema Source Related Servers Discussions Admin

TypeScript

Remote

mcp-kafka

License: MIT npm

A Model Context Protocol server for Apache Kafka. It lets an MCP-capable client (Claude Desktop, Claude Code, etc.) monitor and manage Kafka clusters — topics, partitions, configs, and consumer groups (including lag) — with behaviour controlled entirely by flags.

Safe by default: it starts read-only, can be scoped to an allowlist of topics, protects internal/critical topics from mutation, and gates destructive operations behind an explicit opt-in.

Features

Monitoring — cluster/broker info, topic metadata and offsets, consumer groups, and per-partition + total consumer lag.
Management — create topics, add partitions, alter topic configs, reset group offsets; delete topics/groups (admin).
Access modes — read-only → read-write → admin, layered so a mode never exposes tools above its level.
Security flags — topic allowlist, protected/internal topics, delete gating, dry-run, and JSON audit logging (see below).
Auth — plaintext, TLS, and SASL (PLAIN / SCRAM-SHA-256 / SCRAM-SHA-512).

Related MCP server: Kafka MCP Server

Security model

Concern	Flag	Default	Effect
What can the server do?	`KAFKA_MODE`	`read-only`	`read-only` exposes only monitoring; `read-write` adds management; `admin` adds deletes. Tools above the mode are never registered.
Which topics are in scope?	`KAFKA_TOPIC_ALLOWLIST`	(all)	When set, operations on other topics are refused.
Protect internal topics	`KAFKA_PROTECT_INTERNAL_TOPICS`	`true`	Topics starting with `_` can be read but never mutated.
Protect specific topics	`KAFKA_PROTECTED_TOPICS`	(none)	Additional read-only-forever topics.
Can it delete?	`KAFKA_ALLOW_DELETE`	`false`	`delete_topic` / `delete_consumer_group` need this and admin mode.
Preview without touching the cluster	`KAFKA_DRY_RUN`	`false`	Write/admin tools validate + log intent, then return.
Audit trail	`KAFKA_AUDIT_LOG`	`true`	Emits a JSON line to stderr per guarded operation.
Interactive confirmation	(automatic)	—	Destructive & high-impact actions prompt the human to approve via MCP elicitation before running; clients without elicitation fall back to the `_ALLOW_` gate.

Tools

Read (read-only+): cluster_info, list_topics, describe_topic, topic_offsets, list_consumer_groups, describe_consumer_group (with lag)

Write (read-write+): create_topic, create_partitions, alter_topic_config, reset_consumer_group_offsets

Admin (admin): delete_topic, delete_consumer_group (both need KAFKA_ALLOW_DELETE)

Quickstart — add to your agent

Published on npm as @dockndevai/mcp-kafka. No clone or build needed — your MCP client runs it on demand with npx. Start in read-only mode; see .env.example for every variable and docs/CLIENTS.md for the full per-client guide.

Claude Code (CLI)

claude mcp add kafka -e KAFKA_BROKERS="localhost:9092" -e KAFKA_MODE="read-only" -- npx -y @dockndevai/mcp-kafka

Claude Desktop · Cursor · Windsurf — same block in claude_desktop_config.json, .cursor/mcp.json, or ~/.codeium/windsurf/mcp_config.json:

{
  "mcpServers": {
    "kafka": {
      "command": "npx",
      "args": [
        "-y",
        "@dockndevai/mcp-kafka"
      ],
      "env": {
        "KAFKA_BROKERS": "localhost:9092",
        "KAFKA_MODE": "read-only"
      }
    }
  }
}

OpenAI Codex CLI — in ~/.codex/config.toml:

[mcp_servers.kafka]
command = "npx"
args = ["-y", "@dockndevai/mcp-kafka"]
env = { KAFKA_BROKERS = "localhost:9092", KAFKA_MODE = "read-only" }

VS Code (GitHub Copilot, Agent mode) — in .vscode/mcp.json:

{
  "servers": {
    "kafka": {
      "type": "stdio",
      "command": "npx",
      "args": [
        "-y",
        "@dockndevai/mcp-kafka"
      ],
      "env": {
        "KAFKA_BROKERS": "localhost:9092",
        "KAFKA_MODE": "read-only"
      }
    }
  }
}

Example prompts

"Which consumer groups have the most lag right now?"
"Describe the orders topic and show its offsets."
"Create a topic events with 6 partitions and 7-day retention." (needs read-write)

Run from source (development)

Prefer the published package above. To run from a clone:

npm install
npm run build
node dist/index.js   # with the environment variables set

Develop

npm run dev
npm test
npm run typecheck

Publishing

This server ships a server.json for the official MCP registry and an mcpName for npm ownership validation. See PUBLISHING.md for publishing to npm and listing on the MCP registry, Smithery, Glama, Cursor, and PulseMCP.

License

MIT

Available Tools

6 tools

cluster_infoCluster infoA

Read-onlyIdempotent

Describe the Kafka cluster: brokers, controller, and cluster id.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.3/5.0

Behavior4/5

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

Annotations already declare the operation read-only, idempotent, open-world, and non-destructive. The description adds value by specifying the output scope (brokers, controller, cluster id), which is especially helpful given there is no output schema. No contradiction with annotations.

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

Conciseness5/5

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

A single, front-loaded sentence with no filler. Every word earns its place, and the colon-delimited list makes the scope immediately scannable.

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

Completeness5/5

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

For a zero-parameter, read-only tool, this is complete: annotations cover the safety profile, and the description states the expected return scope. No output schema exists, but the enumerated components give the agent a clear expectation.

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

Parameters4/5

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

The tool takes zero parameters, so the description has no parameter semantics to add. The baseline of 4 for no-parameter tools applies, and the description's component list effectively clarifies what the call returns.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb ('Describe') and resource ('Kafka cluster'), and enumerates the exact components covered ('brokers, controller, and cluster id'). This clearly distinguishes it from sibling tools focused on topics, consumer groups, and offsets.

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

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies the use case by naming the cluster-level resource, but it does not explicitly state when to use this tool over siblings or mention alternatives for topic/group operations. Guidance is left to inference.

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

describe_consumer_groupDescribe consumer group (with lag)A

Read-onlyIdempotent

Describe a consumer group's state and compute per-partition and total lag across its topics.

ParametersJSON Schema

Name	Required	Description	Default
`groupId`	Yes	Consumer group id

TDQS

A3.8/5.0

Behavior3/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is clear. The description adds meaningful behavioral context by noting that lag is computed per-partition and total across topics, but it does not disclose what 'state' includes, whether offsets are committed or current, or what the response structure looks like.

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

Conciseness5/5

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

The description is one tightly written sentence that front-loads the action ('Describe') and packs the essential distinguishing detail ('compute per-partition and total lag') without waste. Every word contributes.

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

Completeness4/5

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

For a simple single-parameter, read-only tool with strong annotations, the description is mostly complete: it states the operation and the expected computed output. It lacks explicit mention of return shape, but no output schema exists and the core outcome is clear enough for an agent to call it successfully.

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

Parameters3/5

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

Schema description coverage is 100% for the single required parameter, groupId, which is documented as 'Consumer group id'. The description adds no parameter-specific meaning beyond that, so the baseline score of 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb ('Describe') with a clear resource ('a consumer group's state') and explicitly states the lag computation over partitions and topics. This clearly distinguishes it from siblings like list_consumer_groups (which lists groups) and topic_offsets (which likely returns offsets without group state).

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

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies when to use the tool—when inspecting a consumer group's state and lag—but it does not explicitly state how it differs from or when to prefer sibling tools like topic_offsets or list_consumer_groups. There is no exclusions or alternative guidance, so usage is inferred rather than explicit.

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

describe_topicDescribe topicA

Read-onlyIdempotent

Partitions, replicas, in-sync replicas, and non-default configs for a topic.

ParametersJSON Schema

Name	Required	Description	Default
`topic`	Yes	Topic name

TDQS

A3.6/5.0

Behavior3/5

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint, and destructiveHint=false. The description adds the specific information returned, but provides no additional behavioral context such as error cases, prerequisites, or output format.

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

Conciseness5/5

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

The description is a single compact sentence that front-loads the key data points returned by the tool. There is no filler, repetition, or unnecessary detail.

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

Completeness4/5

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

For a simple, one-parameter, read-only tool with rich annotations, the description is adequate. It lists the main output contents and the required input, and it does not need to explain complex return types since no output schema exists.

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

Parameters3/5

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

There is only one parameter, topic, and the schema already describes it as 'Topic name' with 100% coverage. The description adds no additional meaning beyond what the input schema provides, so the baseline score of 3 applies.

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 identifies the output of the tool: partitions, replicas, in-sync replicas, and non-default configs for a topic. This distinguishes it from sibling tools like list_topics or topic_offsets, though it lacks an explicit verb and relies on the title 'Describe topic' for the action.

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

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage for inspecting a single topic's metadata by enumerating the returned attributes, but it does not explicitly state when to use this tool over alternatives such as list_topics or describe_consumer_group. No exclusions or routing guidance is provided.

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

list_consumer_groupsList consumer groupsA

Read-onlyIdempotent

List consumer groups and their protocol types.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A3.9/5.0

Behavior3/5

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

The annotations already cover safety semantics: read-only, non-destructive, idempotent, and open-world. The description adds that protocol types are included in the result, but gives no additional behavioral context such as pagination, ordering, or whether all known consumer groups are returned.

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

Conciseness5/5

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

The description is a single sentence that efficiently conveys both the operation and a useful piece of return data. Every word contributes value.

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

Completeness5/5

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

For a parameterless list operation, the description plus annotations are sufficient for an agent to select and invoke it correctly. No output schema exists, but none is needed to know how to call this tool.

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

Parameters4/5

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

The tool has zero parameters and the input schema is empty with perfect coverage. There is nothing for the description to add about parameter meaning, so the baseline of 4 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific action ('List') and resource ('consumer groups'), and names the return content ('protocol types'). It can be distinguished from siblings such as describe_consumer_group and list_topics because 'list' plus the resource clearly signals an overview operation.

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 is given about when to use this tool versus describe_consumer_group for more detail, or when list_topics is more appropriate. The agent must infer the use case from the tool name alone.

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

list_topicsList topicsA

Read-onlyIdempotent

List topic names. Topics outside the allowlist are filtered out.

ParametersJSON Schema

Name	Required	Description	Default
`includeInternal`	No	Include internal topics (starting with _)

TDQS

A4/5.0

Behavior3/5

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

Annotations already communicate read-only, idempotent, non-destructive behavior, so the description only needs to add extra context; the allowlist-filtering statement does that. It does not explain the allowlist semantics or how includeInternal interacts with it, so this is modest rather than thorough.

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

Conciseness5/5

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

Two short sentences, front-loaded with the main action; no filler. Every word earns its place.

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

Completeness4/5

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

A simple enumeration tool with one optional boolean and no output schema; returning names and the filter behavior is enough for an agent to call it. Additional details such as pagination or an allowlist definition would be helpful but are not essential for basic invocation.

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

Parameters3/5

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

The single parameter includeInternal is fully described by the schema (including the '_' convention), and schema coverage is 100%. The description therefore adds little parameter-level value but does not need to.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('list topic names') and makes the filtering behavior explicit. This clearly separates it from descriptive/inspection siblings such as describe_topic and topic_offsets, which focus on details rather than enumeration.

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

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The phrase 'List topic names' establishes the obvious use case: when an agent needs an enumeration of available topics. It does not explicitly name alternatives or exclusions, but the context is clear enough for a read-only listing tool.

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

topic_offsetsTopic offsetsA

Read-onlyIdempotent

Earliest and latest offsets per partition for a topic (message backlog view).

ParametersJSON Schema

Name	Required	Description	Default
`topic`	Yes	Topic name

TDQS

A3.9/5.0

Behavior3/5

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

Annotations already declare the operation read-only, idempotent, and non-destructive, so the description's main contribution is the per-partition, earliest/latest offset semantics. It adds useful context but does not disclose additional behavioral details such as error handling or partition ordering.

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

Conciseness5/5

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

The description is a single, information-dense sentence with no filler. The core output semantics are front-loaded and the parenthetical clarifies the purpose efficiently.

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

Completeness5/5

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

This is a simple one-parameter, read-only tool with strong annotation coverage. The description adequately explains the result shape—earliest and latest offsets per partition—which is sufficient even without an output schema.

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

Parameters3/5

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

Schema coverage is 100% for the single required topic parameter, and the schema already describes it as 'Topic name'. The description does not need to add parameter detail and provides none beyond the context that the topic's offsets are returned.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool returns earliest and latest offsets per partition for a topic. This distinguishes it from siblings like list_topics and describe_topic, which focus on metadata or enumeration rather than offsets/backlog.

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

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The phrase 'message backlog view' implies this tool is for backlog/consumer-lag analysis, but it does not explicitly state when to use it versus alternatives or when not to use it. Usage context is implied rather than stated.

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.

6 tool updatesv0.1.0Aug 23, 2026
- First observedcluster_info
- First observeddescribe_consumer_group
- First observeddescribe_topic
- First observedlist_consumer_groups
- First observedlist_topics
- First observedtopic_offsets

Deploy Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4/5.0

Scored 2026-08-30 20:10 across 6 tools

Disambiguation5/5

Each tool targets a distinct aspect: cluster metadata, topic names, topic configuration, offsets, consumer group listing, and consumer group lag. The only mild overlap is describe_topic vs topic_offsets, but their descriptions clearly separate configuration/replica details from offset ranges.

Naming Consistency4/5

Most tools follow list_* or describe_* verb patterns, which is predictable and clear. However, topic_offsets and cluster_info use noun-style names rather than verb_noun, creating minor inconsistency.

Tool Count5/5

Six tools is well-scoped for a Kafka inspection and monitoring server. Each tool covers a meaningful read-only capability without redundancy or bloat.

Completeness4/5

The set provides solid read-only coverage: cluster info, topic discovery/description, offsets, consumer groups, and lag. It lacks administrative operations like creating/deleting topics or message produce/consume, but those seem outside the likely inspection-focused purpose.

Maintenance

ActivityMaintained

ResponsivenessNo issues

Resources

Need Help?

Related Servers

Related MCP Connectors

OneDroid SynapseOAuth
ai.onedroid
Governed MCP gateway: one endpoint for your tools, with credential custody and audit log.
Security Observability
1
GentkeyOAuth
com.gentkey
One MCP URL for all your connectors — scoped writes, enforced constraints, and a full audit trail.
Developer Tools Security
1
SkycloakOAuth
io.skycloak
Managed Keycloak from any MCP client: clusters, realms, apps, SSO, users, domains, audit events.
Security Cloud Platforms
1
ClearPolicyOAuth
app.clearpolicy
Authenticated MCP server for ClearPolicy policy and compliance workflows.
Legal & Compliance Security
2

Related MCP Servers

mcp-confluentofficial
Cloud Platforms Databases
confluentinc
A
license
B
quality
A
maintenance
An MCP server implementation built to interact with Confluent Kafka and Confluent Cloud REST APIs.
Updated 3 days ago (2026-09-09 18:54 UTC)
24
376
167
MIT
Kafka MCP Server
Databases Monitoring Data Platforms
jilanisayyad
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.
Updated 7 months ago (2026-02-16 15:40 UTC)
MIT
kafka-mcp
Databases Developer Tools Monitoring
wklee610
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).
Updated 20 days ago (2026-08-23 04:59 UTC)
19
13
Apache 2.0
Kafka MCP Server
Data Platforms Developer Tools
Joel-hanson
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.
Updated a year ago (2025-06-07 06:01 UTC)
1
Apache 2.0

mcp-kafka

Features

Security model

Tools

Quickstart — add to your agent

Example prompts

Run from source (development)

Develop

Publishing

License

Available Tools

Tool Schema Changelog

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

mcp-confluentofficial