Kafka MCP
io.github.denizgursoyv0.2.1Updated Oct 7, 2026
Debug Kafka from an agent: find messages, measure consumer lag, unblock consumers, compare clusters.
Overview
Lets an assistant inspect and debug Kafka clusters: list topics, sample and search messages, measure consumer lag, compare clusters, and perform approved…
- What it does
- Connects to one or more Kafka clusters and exposes tools such as list_clusters, list_topics, describe_topic, sample_messages, get_message, get_schema, consumer_lag, describe_consumer_group, open_transactions and compare_clusters. Write tools include create_topic, add_partitions, alter_topic_config, commit_offset, delete_records, delete_topic, delete_consumer_group, produce_message and copy_message. Messages are decoded to JSON via Schema Registry or configured topic formats. Endpoints carry policy: read-only endpoints hide write tools entirely, and every tool call is audit logged.
- When to use it
- Useful when debugging Kafka from an agent: finding a specific message, checking why a consumer group is lagging, comparing preproduction against production, or making an approved change such as creating a topic or committing an offset.
- Requirements
- Runs locally over stdio as a binary, MCP bundle, or container image. Needs a configuration file (CONFIG_FILE) describing clusters, brokers, TLS/SASL credentials, and endpoints; Schema Registry URLs and schema files are optional. Kafka credentials may come from environment variables or secret files. Network access to the brokers is required.
Installation
In SourceWeft
- Open Kafka MCP in the dashboard and add it to a workspace.
- Enable the server for the chats that should use its tools.
Desktop only via STDIO. STDIO servers start a local process, so they need the SourceWeft desktop host.
Other MCP clients
Follow the launch instructions in the repository.
README
kafka-mcp
[License] [Coverage] [Web] [Release] [Kafka MCP server – quality and maintenance score on Glama]
An MCP server that exposes Kafka debugging as tools an LLM can call. It speaks MCP over stdio by default, optionally serves streamable HTTP, and talks to Kafka with franz-go.
One process can connect to several Kafka clusters. In stdio mode, one endpoint is selected for the session. In HTTP mode, each endpoint has its own path, so a session is bound to one cluster by how it connects rather than by a parameter a caller could forget to send.
Install
Every release ships the same server four ways:
-
Binary:
kafka-mcp_<Os>_<arch>archives on the releases page. Putkafka-mcpon yourPATH. -
MCP Bundle:
kafka-mcp_<version>_<os>_<arch>.mcpbon the same page, for macOS on Apple Silicon, Linux (amd64, arm64) and Windows (amd64). Open it in a client that installs bundles, such as Claude Desktop. It asks for your configuration file and, when that file has several endpoints, which one to serve. Intel Macs use the binary or the image. -
Container image:
ghcr.io/denizgursoy/kafka-mcp:<tag>. It starts with--server; for stdio, mount the file and pass--server=false: -
MCP Registry: listed as
io.github.denizgursoy/kafka-mcpin the official registry, with the image and the bundles, so a client that reads the registry can install it from there.
How releases reach the registry and the other catalogs is in PUBLISHING.md.
Configuration
kafka-mcp.{toml,yaml,yml,json} in the working directory, ~/.config/kafka-mcp/ or /etc configures the server. The http block is used only with --server.
clusters owns Kafka connection details: brokers, TLS and SASL. endpoints
owns the policy and, in HTTP mode, the MCP route. Stdio selects an endpoint by
name and does not use its path. Several endpoints may reference one cluster, so
the example reuses one production connection at /kafka-mcp/mcp in read-only
mode and /kafka-mcp/mcp/rw in writable mode. Paths are exact: /mcp does not
capture /mcp/rw. description is optional and is reported by server_config
so a caller knows what the endpoint is intended for.
http.base_path prefixes endpoint paths and the liveness route. A leading or
trailing slash on an endpoint path is optional. Paths must be unique and may
not be /, /healthz, or contain a query or fragment. When path is omitted,
it defaults to /mcp/<endpoint-name>.
For compatibility, a file with no endpoints block still creates one endpoint
per cluster at /mcp/<cluster-name>. Existing cluster-level read_only and
tools values continue to apply as a lower bound during migration; an explicit
endpoint cannot widen them. New configurations should put both fields under
endpoints.
An endpoint may switch individual tools off, by name:
A tool the map does not mention stays exposed, so the file states only what it
withholds rather than relisting every tool and silently losing whatever is added
later. Names are exact and lowercase, as listed by server_config. They are
checked at startup: a name that is not a tool stops the
server, because a typo would leave the tool it was meant to withhold exposed.
server_config cannot be switched off, since it is how a session learns which
cluster and policy it reached and which tools that endpoint has. The tools
map only narrows an endpoint: read_only: true still withholds the writing
tools regardless of what the map says.
A minimal local file:
Run a custom configuration over stdio with
CONFIG_FILE=/path/to/config.yaml go run ./cmd/server. If it defines several
endpoints, select one with --endpoint <name>. Add --server to serve every
configured endpoint over HTTP instead; --endpoint is not used in HTTP mode.
Without CONFIG_FILE, chu discovers kafka-mcp.{toml,yaml,yml,json} first in
the working directory, then in the operating system's user config directory
(~/.config/kafka-mcp/ on Linux), and finally in /etc. It uses the first
matching file rather than merging files. Its standard loader order is defaults,
file, HTTP, then environment; environment overrides use the KAFKA_MCP_ prefix (for example,
KAFKA_MCP_HTTP_ADDRESS=:9000 or
KAFKA_MCP_HTTP_BASE_PATH=/kafka-mcp). Logging can be configured with
LOG_LEVEL and LOG_PRETTY.
At least one cluster with a broker is required. http.address defaults to
:8090, http.base_path defaults to the HTTP root, and output_dir defaults
to the system temp directory. Exports are confined to that directory:
output_file takes a file name, never a path.
brokers accepts either one address as a scalar or several addresses as a YAML
list. Each address is passed to Kafka as a separate seed broker.
Keep secrets out of the file with {env:VAR} or password_file. Unknown fields
are ignored by chu.
TLS is configured with twmb/tlscfg, using its TLS 1.2 minimum and recommended
cipher suites. TLS uses the system trust store;
ca_file adds a custom CA. For mTLS, supply both cert_file and key_file.
security.sasl is a preference-ordered list: each entry enables either scram
or plain, or uses oauth as shown below. For PLAIN, use plain: {enabled: true, user: alice, pass: "{env:KAFKA_PASSWORD}"}.
Both accept optional zid (authorization identity) and password_file instead
of pass; SCRAM also accepts is_token: true for delegation tokens. Algorithms
are case-insensitive. Disabled entries are ignored; repeated mechanisms and
entries enabling multiple mechanisms are rejected. Fallback negotiates a
broker-supported mechanism; it does not retry invalid credentials.
All Kafka connections, including message-reading sessions, use these settings.
Legacy per-cluster tls and sasl: {mechanism, user, password, password_file}
remain supported, but cannot be combined with security on the same cluster.
For OAUTHBEARER client credentials, use this cluster security block:
Alternatively, use oauth: {enabled: true, token: "{env:KAFKA_TOKEN}"} for a
static token. Configure exactly one mode. Client-credentials tokens are fetched
on authentication, cached per cluster across admin and reading connections,
and renewed near expiry using expires_in. Token requests use the current
authentication context and a timeout (default 10 seconds). Static tokens are
not renewed. The broker must support OAUTHBEARER and trust the identity provider.
Broker security.tls settings apply to Kafka connections; HTTPS token endpoints
use the HTTP client's system trust store.
A cluster that cannot be reached at startup is still served, and
list_clusters reports it as disconnected. One cluster being down must not
block debugging the others.
Message formats
Messages are decoded to JSON for every tool that shows or searches them, by the first rule that applies:
- The topic has a format in
topic_formats. - The bytes carry a Schema Registry header (Confluent wire format) and the
cluster has a
schema_registry: Avro, Protobuf (with message index and referenced schemas) or JSON Schema. - Otherwise JSON, then UTF-8 text, then base64.
Formats are avro, protobuf, json, msgpack, text and binary. Schema
files and .proto sources are loaded at startup, so a missing file or type stops
the server. A message that names a schema but cannot be decoded is returned as
base64 with decode_error saying why, never silently. JSON output has sorted
keys; Avro longs beyond 2^53 keep their exact value; unset Protobuf fields are
shown with their defaults.
Each rendered message reports format, schema_id and message_type for the
value, and key_format / key_schema_id when the key is not plain text.
server_config reports the endpoint name, exact path, description, policy and
the cluster it serves, and never the password. Its authentication and
sasl_user describe the first configured option; sasl_options lists all
configured identities in preference order, not the mechanism negotiated by an
individual broker connection. It also reports schema_registry URLs and
topic_formats.
Browser clients (CORS)
A command-line client sends no Origin header and needs none of this. A client
running in a browser does: the browser discards the response unless the server
allows the origin, so the defaults already cover the MCP transport.
http.cors is ada's CORS middleware configuration, read straight from the
file, so every option that middleware has is available here. Each key is
optional and keeps its own default, so setting allow_origins alone does not
drop the rest. The defaults are the values above with allow_origins: ["*"].
Three of them are load-bearing for the MCP transport. allow_methods needs
GET, POST and DELETE: requests are posted, the event stream is a GET,
and a client ends its session with DELETE. allow_headers needs
mcp-session-id and mcp-protocol-version, which the client sends from the
second request onwards, and a header missing there fails the whole preflight
rather than being dropped. Mcp-Session-Id must stay in expose_headers: the
session id arrives on the initialize response, and a page that cannot read
it cannot make a second call.
allow_private_network answers Chrome's Private Network Access preflight,
which a page on a public address must pass before it may reach a server on a
private or loopback address; it defaults to on, and is granted only on a
preflight the rest of the policy already allowed. Setting allow_credentials
together with a wildcard allow_origins is refused by the middleware at
startup unless unsafe_wildcard_origin_with_allow_credentials is also set,
which it should not be.
These endpoints have no authentication of their own. An allowed origin can
drive every tool with the server's Kafka credentials, from any page the
browser's user happens to visit. allow_origins is the only built-in HTTP
barrier, so narrow it to the pages that should have that power, protect writable
paths in a reverse proxy, and set read_only: true on endpoints that should not
write. A less obvious path such as /mcp/rw is not authentication.
Connecting a client
For the default stdio transport, configure the client to launch the binary. A configuration with one endpoint needs no arguments:
When the file contains several endpoints, add the endpoint selection to the
command, for example "command": ["kafka-mcp", "--endpoint", "prod-read"].
The process refuses to start without it so it cannot silently connect a session
to the wrong cluster or permission policy.
To use HTTP, start kafka-mcp --server and register one remote client entry per
endpoint:
The key becomes the tool prefix, so these appear as kafka-local_list_topics
and kafka-prod-read_list_topics. Name entries after both the cluster and the
endpoint policy: the prefix is the clearest signal of what a call can hit and
change. Use server_config to confirm rather than trusting the client-side
name.
Each enabled cluster costs context: these tools are roughly 8k tokens of definitions. Enable only what you need, and put production behind an agent:
Permissions
Three layers, and only one of them is real security:
What a read-only endpoint exposes
read_only: true does more than refuse a write: the endpoint does not list the
tools whose only purpose is to write. add_partitions, alter_topic_config,
commit_offset, create_topic, delete_consumer_group, delete_records and
delete_topic are absent from tools/list on a read-only endpoint, so a client never sees a tool it could not have used, and their
preview cannot describe a change this endpoint would never apply.
A writable endpoint can withhold individual tools too, with its tools map.
That is the same mechanism seen from the client: the tool is
not registered, so it is absent from tools/list and from server_config.
copy_message and produce_message stay, because read_only protects the
cluster being written to and the destination is chosen per call. Copying a
message out of a read-only production cluster, or seeding a writable preprod
cluster from a protected session, is exactly what they are for. Both refuse
outright when the destination is the read-only cluster itself.
Hiding a tool decides what is advertised, not what is permitted: both tools
still refuse at the point of mutation, so a registration mistake cannot turn
into a write. server_config reports the tools the endpoint actually exposes,
which is how a session can tell the two cases apart.
Giving two people different permissions
Kafka enforces permissions against the SASL principal, so two people running
the same server with different credentials get different rights. Adding
partitions requires ALTER on the topic:
Each points CONFIG_FILE at their own file, differing only in security.sasl[0].scram.user
and the password. When ali calls add_partitions, the broker refuses:
ali cannot bypass that by editing config or rebuilding the binary, because the
decision is made by Kafka rather than by this server. On a cluster without
ACLs, read_only: true is the available protection.
Audit logging
Every tool call is logged. One slog record per call, on the server's own log
stream, so nothing extra has to be configured:
The tools that change a cluster — add_partitions, alter_topic_config,
commit_offset, create_topic, copy_message, delete_consumer_group,
delete_records, delete_topic, produce_message — are logged at INFO.
Everything else is logged at DEBUG, because reads are constant and change
nothing, so recording them at the same level would bury the writes among them.
Raise the log level to see them.
Two fields carry most of the weight. confirm separates a real write from a
preview, and targets names the topic, group, partition and offset each item
pointed at, so a record says which topic was touched rather than only that some
topic was.
Message content is never logged. produce_message and copy_message carry
arbitrary payloads, and an audit log is usually readable by more people than the
data it describes, so keys, values and headers are left out. The audit code has
no field to unmarshal them into, so content cannot reach a log even by mistake.
None of the recorded identities is a person, and the server cannot make one up. What each actually means:
For attribution to a person, give each person their own endpoint and SASL
credentials, as above: the principal in the record is then the answer to who
acted. A shared credential cannot be made to answer it.
Tools
Batch operations
describe_topic, sample_messages, get_message, get_schema,
consumer_lag, describe_consumer_group, open_transactions,
add_partitions, alter_topic_config, create_topic, commit_offset,
delete_consumer_group, delete_records, delete_topic, copy_message and
produce_message take their target only as a required items array. There
is no single-target form: one operation is an items array of length one.
Everything naming or shaping an operation lives on the item, so each field and
its description exist in exactly one place. What governs the whole call stays at
the top level, which in practice means confirm.
The message-heavy tools accept at most 20 items; lag, schema and administrative tools accept at most 100.
Every response is the same envelope. Results stay in input order, each entry
carrying index and either result or error, followed by succeeded,
failed, applied and atomic: false. An item's failure is data in the
response rather than an error for the call, so it never hides the items that
worked. Batch writes preview every item first, then apply the valid ones only
when the top-level confirm is true. They are not transactions: Kafka cannot
roll back a topic, partition, offset or produced message after a later item
fails. Duplicate write targets are refused before anything changes, except in
produce_message, where two identical items mean two messages rather than a
mistake.
list_clusters
Lists the clusters this server serves, with whether each is reachable and
whether it accepts writes. Takes no parameters. Available from every endpoint,
so a session can discover what copy_message, produce_message and
compare_clusters may target.
connected is checked when you call, not recorded at startup, so a cluster
that has since gone down is reported honestly. Only the name, reachability and
writability are reported: broker addresses and credentials are deliberately
not, because this tool is reachable from every endpoint.
compare_clusters
Compares the topics of other clusters against the one this endpoint serves, and reports what differs. Use it to find what preproduction has that production does not, or to check whether two environments still match.
Item fields:
only_here and only_there name the direction, which is decided by the
endpoint you call: "here" is always the cluster this endpoint serves. Entries
carry the partition count, replication factor and explicitly-set configs of the
cluster that has the topic, so they can be passed straight to create_topic.
This tool creates and changes nothing. To create the missing topics, hand
the chosen entries to create_topic, which previews them against the broker
first and warns that a partition count can never be reduced.
differing is usually the more valuable half: a topic that exists on both sides
with a different partition count or retention.ms is the common reason a bug
reproduces in one environment and not the other. Only configs a topic sets for
itself are compared, because two clusters may carry different broker defaults
and comparing inherited values would report every topic as different.
A difference is not necessarily a mistake. A topic missing from production is often deliberate, so the report says what differs, never what is correct.
Topic listings come from the Kafka client's metadata cache, which is a few
seconds old, so a topic created moments earlier may still appear in
only_there. Repeat the comparison rather than creating it twice.
list_topics
Lists the topics on the cluster, sorted by name, each with its partition count, replication factor and the configs it sets for itself.
The predicate sees:
Filtering is JavaScript only, as it is for search_messages: a name match is
return topic.indexOf('orders') >= 0. The predicate can also answer what a
substring never could — which topics have more than six partitions, only one
replica, or a compacted cleanup policy.
Only configs a topic sets for itself are reported. Inherited cluster defaults are excluded, because including them would make every topic look configured.
A topic whose predicate throws, or is cut short by the timeout, is counted in
script_errors rather than listed, so a broken filter is never mistaken for an
empty cluster.
describe_topic
Reports a topic's partitions, offset ranges, message count, time span and full configuration. Use it before searching to see how much data a search would read and how far back the topic can hold data at all.
Item fields:
configs lists every topic config as the string Kafka reports, where -1
means unlimited. is_default is true when the value is inherited rather than
set on the topic. Two entries decide whether a message can still exist at all:
retention.ms (how long messages are kept) and cleanup.policy (compact
keeps only the latest message per key).
sample_messages
Reads a small sample of the newest messages and reports what they look like: value formats, field paths with their types, key statistics, which value fields carry the message key, and the schemas the values were written with. Avro, Protobuf and JSON Schema values are decoded first, so their field paths are reported like JSON. Use it before searching to decide how to search, and before producing to find the schema to write against.
Item fields:
key_in_value naming a field means the key is that identifier, so searching
the key alone is the precise, cheap lookup. value_formats also counts avro,
protobuf, json_schema, msgpack, null and undecodable — values that
named a schema but could not be decoded, which is a configuration problem, not
binary data.
search_messages
Scans a bounded range of a topic, filtering messages with a JavaScript expression. Kafka has no server-side search, so this reads messages and filters them client-side; the result reports what was covered.
The script
Return true to keep a message. In scope:
Searching by key exactly is far more precise than searching the body: 123
also appears inside "amount": 1123, and those false positives can fill
max_matches and hide the message wanted.
A script that throws on a message is counted in script_errors and the scan
continues, so a broken script is distinguishable from a genuine absence of
matches. Scripts run in a sandbox with no filesystem, network or host access,
and are stopped if they exceed the search timeout. They are not bounded by
memory: something like 'x'.repeat(1e12) can exhaust the server process.
Scripts are trusted input; the blast radius is this server, not the cluster.
Scan order
Every partition is read together, one chunk deep at a time: the newest chunk of every partition, then the chunk behind it, and so on. A limited newest-first search therefore returns the newest matches in the topic, not the newest in whichever partition happened to be read first.
Kafka orders records within a partition and never across them, so matches are
merged and reported by timestamp, with partition and offset breaking ties.
Timestamps are set by the producer unless the topic uses LogAppendTime, so
they can be skewed; it is still the only thing comparable between partitions.
One scan reads every partition through a single connection, so a wide topic
costs no more connections than a narrow one. It does read more: a limited
search on a 12-partition topic examines the newest chunk of all twelve rather
than stopping inside the first. max_messages_scanned still bounds it, and may
become the stopped_reason on a wide topic sooner than on a narrow one.
Parallelism
parallelism splits a single-partition topic's offset range between that
many readers, which is what makes a full scan of one large partition fast. A
multi-partition topic is already read in parallel across its partitions, so the
setting does not apply there, and a range too small to divide is read by one
reader.
It pays off for count_only, output_file and full scans of a single
partition.
Result
complete is true only when the whole range was read. An empty match list
means "not there" only if complete is true; otherwise check stopped_reason
and narrow the search.
For large result sets, use count_only to learn how many matches exist, then
output_file to write them out instead of returning them.
get_message
Reads messages at exact offsets, plus optional neighbours.
Item fields:
Schema-encoded values are decoded to JSON, with format, schema_id and
message_type saying what they were. Values that could not be decoded and are
not valid UTF-8 are base64 encoded, with encoding set to base64;
decode_error explains a value that named a schema but could not be decoded.
get_schema
Reads schemas from the cluster's Schema Registry, by subject or by the
schema_id a message carries. Read the schema before producing to a
schema-encoded topic: it names every field and enum a value needs, which a
sampled message may not show.
Item fields, giving subject or id:
message_types lists Protobuf messages, which produce_message takes as
message_type. Looking up an id fills used_by with the subject versions
that use it. The call fails as a whole when the cluster has no
schema_registry.
list_consumer_groups
Lists consumer groups with their state, member count and the topics they consume.
A group in state Empty can still report lag: committed offsets outlive the
consumers that made them. Kafka has no topic-to-group index, so filtering by
topic describes every group on the cluster.
describe_consumer_group
Describes consumer groups in detail: who the members are, which partitions each one owns, and where the group stands on every partition. Use it to turn "a partition is stuck" into "this pod on this host is stuck".
Partitions are the union of what members own and what the group has committed,
so an Empty group still shows its positions. has_commit: false means the
group owns a partition it has never committed on, so where it starts is decided
by the consumer's auto.offset.reset, not by an offset.
open_transactions
Finds open transactions holding back read_committed consumers. A transactional
producer that hangs or dies mid-transaction leaves the partition's last stable
offset stuck, and every read_committed consumer stops there. In
consumer_lag that looks exactly like a poison message.
The fix is in the producer: restart or fence the application named by
transactional_id, or wait for timeout_ms, after which the broker aborts the
transaction. Moving the consumer's offset does not help.
consumer_lag
Measures how far behind a topic's consumers are, how fast messages are produced and consumed, and when the backlog will clear.
Item fields:
Sampling windows run concurrently, so several measurements do not add their waits together.
The two rates are measured differently, and the output says so:
produce_rate— historical fact, from message timestamps, over the last second, minute and hour.window_truncatedmarks a topic younger than the window.consume_rate— a sample: the committed offset is read, then read againsample_secondslater.sample_inconclusivemeans nothing moved.
The backlog drains at the consume rate minus the produce rate. status
says what the numbers mean: caught_up, draining (with an ETA), growing
(never clears, with growing_by_per_minute), stalled, no_active_consumers,
or not_measured. An ETA is only given when the lag is genuinely shrinking.
cluster_health
Checks the cluster this endpoint serves in one call: brokers, controller, and every partition that is not fully healthy.
offline means the partition has no leader, so nothing can be read or written.
under_replicated means a replica is out of sync. under_min_isr is the
condition behind NOT_ENOUGH_REPLICAS: producers using acks=all fail until
the in-sync replicas recover. A broker leading no partitions while others lead
many is usually one that restarted and was never given leadership back.
Some Kafka-compatible brokers, Redpanda among them, do not report
min.insync.replicas. The topics affected are listed in min_isr_unknown, and
under_min_isr is not judged for them rather than guessed.
list_acls
Lists access control entries, for when a client fails with
TOPIC_AUTHORIZATION_FAILED or GROUP_AUTHORIZATION_FAILED.
A deny overrides every allow. A broker without an authorizer fails with
SECURITY_DISABLED, which means ACLs are not enforced at all.
server_config
Reports the effective configuration: endpoint name, exact path, description, cluster, brokers, authentication mechanism and principal, TLS, read-only state, export directory and the tools this endpoint exposes. Takes no parameters. The password is never reported.
tools is the list for this endpoint, not for the deployment: a read-only
endpoint omits add_partitions, alter_topic_config, commit_offset,
create_topic, delete_consumer_group, delete_records and delete_topic,
because it
does not register them, and any endpoint omits whatever its tools
configuration switches off.
Use it when a result is surprising: an empty topic list means something very different on a local broker than on production.
add_partitions
Adds partitions to a topic. Irreversible — Kafka cannot reduce a partition count. Not exposed on a read-only endpoint.
Item fields:
Without confirm it reports what would happen: current and target counts,
whether messages are keyed, which consumer groups will rebalance, and warnings.
Adding partitions changes which partition a key hashes to, so existing keys
lose their ordering guarantee. A keyed topic therefore requires
acknowledge_key_ordering as well. Requesting fewer partitions than the topic
has is refused with an explanation rather than attempted.
alter_topic_config
Changes topic-level configuration: retention, cleanup policy, maximum message size and anything else Kafka allows per topic. Changes are incremental, so every key not named keeps its value. Not exposed on a read-only endpoint.
Item fields:
The preview asks the broker to validate the change, so an unknown key or an
invalid value is refused before confirm. Shortening retention.ms reports how
many messages are already past the new limit; changing cleanup.policy or
setting retention.bytes is warned about. After applying, every key is re-read
from the broker, which is the only way the inherited value of a deleted override
is known.
create_topic
Creates a topic. Refuses a topic that already exists rather than adjusting it. Not exposed on a read-only endpoint.
Item fields:
Without confirm the request is sent to the broker with ValidateOnly, so the
preview reports the cluster's own answer — an invalid name, an unknown config
key, a replication factor larger than the cluster — rather than a guess. With
confirm the topic is created and the resulting partition count and
replication factor are read back from the cluster, which is how an omitted
count is reported as the number the broker actually chose.
Using broker defaults requires Kafka 2.4 or newer, whose CreateTopics v4 API
introduced -1 as "use the broker default". On an older broker, pass both
counts explicitly.
A replication factor larger than the number of brokers is refused here, with the broker count in the message, because brokers differ on whether a validate-only request catches it.
Use add_partitions to change an existing topic's partition count; this tool
never modifies a topic it did not create.
delete_topic
Deletes topics. The most destructive tool here: deleting a topic destroys every message in it, Kafka has no undo, and any consumer group reading it breaks. Not exposed on a read-only endpoint.
Item fields:
Without confirm it reports, per topic, how many messages would be destroyed,
how many partitions it had, and which consumer groups had committed offsets for
it:
Two separate acknowledgements are required, because they answer different
questions. confirm says the caller meant to delete; acknowledge_data_loss
says they know what is inside. A topic holding messages is refused without both,
and the count is re-read at deletion time, so a topic that gained messages since
the preview is still caught.
Internal topics such as __consumer_offsets are refused outright at any level
of acknowledgement: they hold cluster state rather than a caller's data, and
deleting one breaks every consumer at once.
Duplicate topics in one batch are refused before anything is deleted. Deletion is not atomic — topics removed before a later item failed stay removed.
delete_records
Deletes the oldest messages of a partition without deleting the topic. The topic, its configuration and its consumer groups stay. Irreversible. Not exposed on a read-only endpoint.
Item fields:
affected_groups lists every group committed below the cut, with how many
messages it would lose without ever processing them; such a group resumes from
the new start. Use the partition's end offset as before_offset to empty it.
delete_consumer_group
Deletes consumer groups and their committed offsets. Use it to clean up groups whose consumers were decommissioned: their commits keep reporting lag that nobody will ever drain. Not exposed on a read-only endpoint.
The preview lists each group's committed offsets and lag. A group with active
members is refused, and re-checked at deletion time. A consumer that later
starts with the same group id begins from its auto.offset.reset, not from
where the group left off.
commit_offset
Moves consumer groups' committed offsets. Forward to skip messages, backward to replay them, or to a point in time to reprocess everything since. Irreversible in the sense that skipped messages are never processed. Not exposed on a read-only endpoint.
Item fields — give exactly one of offset, timestamp or position:
A partition with no message at or after timestamp moves to its end, and its
entry carries a note saying so. A whole-topic item and a partition item for
the same group and topic in one batch are refused, because which one wins would
depend on order.
The group must have no active members. A running consumer keeps its position in memory and only reads the committed offset when it joins, so a commit made while it runs is overwritten by its next commit and the group does not move. Stop the consumers first.
copy_message
Copies messages to another topic, preserving key, value and headers. Takes each message's address, never its content, so it can only duplicate a message the cluster already holds.
Item fields:
Set destination_cluster to copy into another cluster this server serves,
which is how a production message is taken into a preproduction topic to be
debugged safely. Use list_clusters to see which names are valid.
Every copy carries provenance headers — kafka-mcp-copied-from-cluster,
-from-topic, -from-partition, -from-offset, -copied-at,
-copied-by-tool, -copied-by-principal — so a message in a dead letter or
preproduction topic can be traced back to its original. If the message already
carries one of those headers, the original is kept and the collision is
reported.
Key and value bytes are copied unchanged. A schema id is only meaningful in the
registry that issued it, so when the destination cluster uses a different
registry, or none, the response warns. With translate_schema the schema is
registered in the destination registry under <destination_topic>-value (or
-key), with its references, and the id in the copy is rewritten; the payload
is untouched. That registration is a write to the destination registry and
happens only with confirm.
For a copy within the endpoint's own cluster, its read_only policy protects
the destination. A read-only endpoint can still be the source of a
cross-cluster copy, because copying out changes nothing there. A different
destination cluster is writable when it has at least one writable endpoint;
list_clusters reports that effective state. The tool is refused entirely
when the destination is read-only, preview included, because writing is all it
does.
produce_message
Writes new messages to existing topics. Unlike copy_message, the caller
supplies the content, so this can put a message into a topic that no producer
ever sent.
Item fields:
Every message carries kafka-mcp-produced-at, kafka-mcp-produced-by-tool,
kafka-mcp-produced-by-principal and, when the client identifies itself,
kafka-mcp-produced-by-client, so a fabricated message stays distinguishable
from a genuine one. A header the caller supplies under one of those names is
kept as given and the collision is reported.
value_schema and key_schema take {subject, version, id, message_type},
all optional: {} means the latest version of <topic>-value (or -key) in
the destination cluster's registry, id pins an exact schema, and
message_type picks a Protobuf message. The value is given as JSON, validated
against the schema in the preview — a missing or misspelt field is refused by
name — and written framed with the schema id, as registry-aware consumers
expect. A topic with a format in topic_formats is encoded to it without being
asked. Neither can be combined with encoding: base64. The response reports
the schema used in value_encoding / key_encoding.
The topic must already exist: a missing one is refused rather than left to
auto-creation. Omit partition unless the exact partition is the point — the
key decides placement, and naming a partition puts a keyed message where its
key does not hash to, which breaks ordering for that key. The response warns
whenever an explicit partition is used.
read_only protects the cluster being written to, so a read-only endpoint may
still produce into a different, writable cluster, and is refused outright —
preview included — when writing to its own. A produced message cannot be
deleted; it stays until retention removes it.
Skills
skills/kafka-debugging/SKILL.md is the one skill an agent loads. It routes to
the scenario guides under skills/kafka-debugging/references/, rather than
holding every workflow itself, so a session reads only the one it needs:
find-message.md— locating a message from something the user knows about it.check-lag.md— measuring lag and throughput, and judging when a backlog will clear.scale-partitions.md— deciding whether more partitions will help, and adding them safely.skip-poison-message.md— unblocking a consumer stuck on a message it cannot process, preserving the message first.create-topic.md— creating a topic with a partition count and retention chosen on purpose, including as acopy_messagedestination.produce-message.md— writing a message: repairing and re-injecting one, reproducing a failure in another cluster, or seeding a topic.compare-clusters.md— finding what differs between two environments, and creating the topics one of them is missing.delete-topic.md— removing a topic and everything in it, after the user has seen what that destroys.replay-messages.md— reprocessing everything since a moment, after a bug fix ships.tune-topic-config.md— changing retention, cleanup policy or message size on a topic, knowing what the change does to data already there.cluster-health.md— finding offline and under-replicated partitions behindNOT_ENOUGH_REPLICASand unreadable topics.purge-messages.md— deleting old messages from a partition while keeping the topic, or removing abandoned consumer groups.authorization-error.md— working out which ACL is refusing a client.
The umbrella also resolves the overlap between them: "the consumer is behind"
opens three of these guides, and consumer_lag's status is what decides which
one is right.
Development
The documentation site lives in _docs (Vite, pnpm). pnpm install && pnpm dev
there serves it locally; pushing changes under _docs/ to main publishes it to
GitHub Pages through .github/workflows/docs.yml.
Tests run against real containers started by internal/domain/testenv (a Redpanda
broker plus Console), so Docker must be available for the full suite.
Start the HTTP server
Requires Go 1.27 or later. Configuration is loaded with chu; set CONFIG_FILE
to select a YAML or JSON file. into manages the process lifecycle, ada serves
HTTP with context-driven shutdown, and logi initializes structured logging.
kafka-mcp.local.yaml is committed and points at the compose broker, so a
clone works without writing any configuration. make env-up publishes the broker
on localhost:19092, the Schema Registry on localhost:18081 and the Redpanda
Console on http://localhost:8080.
Check it is up:
Source: README.md at commit d2a70c8
Tools
0Version history
1- v0.2.1LatestOct 7, 2026
More servers like Kafka MCP
PG Bloat Detective
io.github.r69shabh
Read-only Postgres bloat diagnosis: table and index verdicts, blocker identification, timelines, and REINDEX proof.
Whyts
io.github.musatoktas
Runs a measured TypeScript compiler analysis to show why a project's type checking is slow, and compares before/after runs.
Vibeflow
io.github.zorcec
Vibeflow is a local Kanban task server that lets an assistant read, create, and update UI-fix tickets annotated with CSS selectors and source locations.