Best Kafka MCP servers

A Kafka MCP server exposes Kafka operations, such as listing topics, reading consumer lag or creating a topic, as tools an AI assistant calls through the Model Context Protocol.

The options today are vendor servers (Factor House, Confluent, Google Cloud, Aiven, Lenses, Conduktor, WarpStream, StreamNative, Redpanda), open-source UIs with a built-in endpoint (Kafbat UI), community servers, Kubernetes-level servers for Strimzi, and plain shell access to the Kafka CLI.

They differ less on what they can read than on governance: what the agent may change, whose permissions it runs with, whether anyone can see what it did, and whether message contents reach the model. Kpow is Factor House’s product, and I work at Factor House as a Solutions Architect, so it is scored on the same rubric and the same sources as every other option. The Kpow MCP server ships with version 2 of the Kpow API, and it is scored on the same six criteria and the same sources as the rest. The complete Kafka guide covers the wider tooling picture.

What a Kafka MCP server is

The Model Context Protocol defines how a server advertises tools and how an AI client calls them. A Kafka MCP server sits between the assistant and a live cluster: the assistant decides which tool to call, and the server turns that call into Admin API requests, consumer reads or REST calls against the cluster.

Every server on this page connects to Kafka with some credential. The question that decides whether it is safe is whose credential that is, and what it is allowed to do. The protocol’s tools specification states that “there SHOULD always be a human in the loop with the ability to deny tool invocations”, and leaves the enforcement to the client and server you choose.

What a Kafka MCP server lets an agent do

The common tool surface is the day-to-day operator workload:

• inspect topics, partitions, configs and brokers
• read consumer group state and lag per partition
• read sample messages from a topic
• restart, pause or reconfigure connectors
• create topics, change configs, reset offsets and, on some servers, delete topics or whole clusters

The first three are diagnosis and the last two change the cluster. In our own preview of an AI assistant working against Kafka, the useful part was diagnosis: asked why two connectors had failed, the assistant concluded it was a catalog issue, not a connector issue, and that “restarting the connector will just fail until that’s fixed”. The fix, creating the tables by hand and turning off auto-create, was a human decision. That split between reading and changing is the spine of the rubric below.

How we scored them

Six criteria, applied the same way to every option. Each score comes from the option’s own documentation or README as read on 22 and 23 September 2026, and anything the docs do not state scores low, because an unstated control is not one you can rely on in production.

1. Read vs write scope

Can you run the server read-only, and if it writes, can you narrow which writes it has? The best answer is a read-only default with an allowlist for specific writes. The worst is a server that registers delete-topics and leaves the rest to the model’s judgement.

I apply this to myself. When I needed to reverse engineer some Terraform in our own AWS account, I created a read-only role first so I could inspect everything without any chance of deleting it, then logged out of the admin role. An agent deserves the same starting point.

2. Permission model

Does the agent act as a specific identity whose permissions are enforced server-side, or as one shared credential? Per-user OAuth or OIDC with resource-level scopes scores high. A server that inherits a single Kafka principal scores low, because every person who points an assistant at it gets that principal’s full reach.

The governance problem with most MCP servers is simple: they are a thin wrapper over one credential. The MCP security best practices make the same point about scope: “Poor scope design increases token compromise impact, elevates user friction, and obscures audit trails.”

3. Audit of agent actions

Is each tool call recorded with the identity that made it, somewhere your team already looks? At Current London 2025, Derek, our co-founder and CEO, recorded one engineer’s line that sums up the requirement: “If an LLM is making decisions in my pipeline, I want to know what it saw, why it acted, and how to stop it fast.” A tool-call log attributed to a principal answers the first two. Broker-side logs alone record the principal but not the prompt that led to the call, as the layers in Kafka audit logging tools show.

4. Approval for destructive operations

Can a delete, offset reset or config change be held until a human says yes? OWASP’s LLM06 Excessive Agency lists excessive autonomy as a root cause, where an application “fails to independently verify and approve high-impact actions”. A startup flag that disables deletes is better than nothing. A per-action approval step is better still. A read-only server has nothing to approve, and it scores in the middle, because it also cannot carry out a change you have approved.

5. Message contents sent to the model

Does reading a topic put raw records, including any PII in them, into the model’s context? In the demo I said an agent is only as good as the context you give it, and that cuts both ways: everything a tool returns becomes context, and context leaves your cluster for the model provider. No Kafka MCP server on this page documents masking of message contents before they reach the model. The best available answers are servers with no record-reading tools, or ones where the consume tools can be switched off.

6. Availability and cost a year

Can you run it where your Kafka runs, is it released for production use, and what does it cost a year? A hosted server that only works on one vendor’s cloud scores lower for everyone else. A beta, a proposal or an announcement scores near zero, whatever its design. A high modelled total pulls the score down even where the licence line is nothing.

The dollar figures on the cards are our own model, not a vendor quote. The model is three Kafka clusters and engineering time at $120 an hour, a published price is used unchanged, and each option’s total is built from these lines:

• its published licence, or a note that the vendor quotes rather than publishes one, in which case the total covers time only and is not comparable
• the engineer-hours a month it takes to deploy, credential and keep the access path current, across three clusters
• $5,760, 4 engineer-hours a month, where the server runs beside a tool that already carries a run cost of its own, because the MCP surface is enabled, credentialed and kept current separately from the tool it fronts
• $4,800, one 40-hour incident reconstruction a year, where criterion 3 scores 3 or lower, because without a tool-call log somebody rebuilds what the agent did from broker logs
• $2,880, 24 hours a year, where criterion 1 scores 4 or lower, to write and review the Kafka ACLs or IAM conditions the server does not give you
• $2,400, 20 hours a year, where there is no vendor to call, to read and pin each release yourself

Kafka MCP servers compared

The table scores each option on the criteria above, in the same order. Rows are ranked in the same order as the cards, with our own product first, Conduktor last, and everything between it by total. The rows the cards group together sit next to each other at that card’s place, and the options the page lists without a card of their own are placed by the evidence in their own cells. Where a vendor’s documentation is the only source, it is named in text rather than linked.

Rank	Option	Status and deployment	Read vs write scope	Permission model	Audit of agent actions	Approval for destructive ops	Message contents to the model	Source
1	Kpow	Generally available with Kpow API v2. Self-hosted with Kpow, any cluster Kpow reaches. $16,380 a year on our model	No tool list published. RBAC can allow, deny or stage each action	Existing OIDC SSO, RBAC and tenancy, stated for agentic users	Kpow audit log records API and UI actions. Not stated for MCP	RBAC Stage effect sends mutations to an admin. Not stated for MCP	Masking enforced server-side on API responses. Not stated for MCP	Demo page, Kpow docs
2	Confluent managed MCP	Documented. Hosted, Confluent Cloud only	Mostly read-only. Two connector tools mutate	Confluent Cloud RBAC via Global, Cloud or Flink API keys. No resource-scoped keys	Every call in the Cloud audit log as mcp.tools/call, with the principal	Not stated	Reads 1 to 10 sample messages. Masking not stated	Confluent’s documentation, Managed MCP server page
3	Redpanda Agentic Data Plane	Documented, audit log in preview. Redpanda-hosted gateway	Via access policies	OIDC on-behalf-of auth, Cedar policies	Audit log incl. tools/call, preview	Not stated	Can record a Masked outcome from a guardrail	Redpanda’s documentation, Agentic Data Plane pages
4	Instaclustr for MCP Gateway	Announced production-ready in a vendor blog. Managed	Only operator-defined parametrised tools	Personas, each with its own OAuth client	Gateway usage audit log	Not stated	Not stated	Instaclustr blog, 30 June 2026
5	WarpStream Console MCP	Documented. Hosted control plane, WarpStream only	Read-only keys	Keys scoped to selected workspaces	Not stated	Nothing to approve	Control-plane APIs only	WarpStream’s documentation, MCP server page
6	kafka-sentinel-mcp	Active, 3 stars. Local	Read-only by construction	Inherits the Kafka principal	Every call logged with parameters	Nothing to approve	Not stated	GitHub: sanjay-amu/kafka-sentinel-mcp
7	KIP-1318	Under Discussion. Nothing to run	Proposed read and mutation separation	Proposed topic scoping	Proposed tamper-evident trail	Proposed	Redaction in reference code only	KIP-1318
8	AKHQ	Not shipped. Pull request open	Proposed read-only tools	Proposed: existing topic-data permissions	Not stated	n/a	Proposed tools read messages	GitHub: akhq PR 3236
9	Lenses MCP	Shipped from Lenses 6.2. Self-hosted sidecar to HQ	Grant only the read scope	OAuth 2.1 read, write and delete scopes, validated by HQ	Lenses Audits exists. Not stated for MCP	Not stated	SQL over topic data. Masking not stated	GitHub: lensesio/lenses-mcp
10	kubernetes-mcp-server	Active. Local or in-cluster	read_only, disable_destructive	Kubernetes ServiceAccount RBAC	Kubernetes API audit, not stated in README	Not stated	Operates resources, not records	GitHub: containers/kubernetes-mcp-server
11	Strimzi Kafka CLI MCP	Active. Local against Kubernetes	Create and delete Kafka clusters, topics, users	Kubernetes credentials	Not stated	Not stated	Operates resources, not records	GitHub: SystemCraftsman/strimzi-kafka-cli
12	Aiven MCP	Active. Aiven-hosted or local, Aiven only	read_only, write_allowlist, services_scope	Aiven user permissions	Not stated	Not stated	Reads messages. Credentials hidden by default	GitHub: Aiven-Open/mcp-aiven
13	Google Cloud Managed Kafka MCP	Global endpoint GA, regional in Preview. Google-hosted	Includes delete_cluster and delete_topic. No read-only mode documented	Google Cloud IAM, setup asks for Managed Kafka Admin	Centralized audit logging listed for Google remote MCP servers	Not documented	No record-reading tools. Optional Model Armor screening	Google Cloud docs
14	StreamNative MCP	Active. Self-hosted, external Kafka supported	--read-only, --features	Inherits configured credentials	Not stated	Not stated	Consume tools can be left out	GitHub: streamnative/streamnative-mcp-server
15	Shell access to the Kafka CLI	Always available	Anything the principal can do	Kafka ACLs on the principal	Broker authorizer log	Agent’s own prompts. kcl dry-runs when non-interactive	Raw records	Apache Kafka ACL docs
16	Kafbat UI MCP	Opt-in, SSE only. Self-hosted	Honours per-cluster read-only (source code)	Not stated whether UI RBAC applies	UI audit log. Not stated for MCP	Not stated	Masking documented for Messages page only	Kafbat docs
17	Redpanda Cloud MCP	Beta, not for production. Local via rpk	Deletes need --allow-delete	rpk cloud login identity	Not stated	Startup flag only	Not stated	Redpanda’s documentation, Cloud MCP pages
18	mcp-confluent	Active, community-supported. Self-hosted, any Kafka	Full writes incl. delete-topics. Allow and block lists	Inherits the configured key	Not stated	Not stated	consume-messages returns records	GitHub: confluentinc/mcp-confluent
19	wklee610/kafka-mcp	Active	Topic create and delete, offset resets, produce	Inherits the principal	Execution audit logging for offset tools	Dry runs for offset tools	Consume returns records	GitHub: wklee610/kafka-mcp
20	gAmUssA/mcp-kafka	Active	Topics, produce, schemas. Allow and block lists	Inherits the principal. No auth on HTTP yet	Not stated	Not stated	Consume returns records	GitHub: gAmUssA/mcp-kafka
21	tuannvm/kafka-mcp-server	Last commit Nov 2025. Local	Produce	Inherits the principal. OAuth 2.1 on HTTP	Not stated	Not stated	Consume returns records	GitHub: tuannvm/kafka-mcp-server
22	kanapuli/mcp-kafka	Stale, last commit Mar 2025	Create and delete topics, produce	Inherits the principal. No SASL_SSL	Not stated	Not stated	Consume returns records	GitHub: kanapuli/mcp-kafka
23	Confluent Cloud Claude Code plugin	Active repo. Local, in Claude Code	Creates and deletes environments, clusters, topics and API keys	Inherits the Cloud API key	Not stated	Not stated	Not stated	GitHub: confluentinc/claude-code-confluent-plugin
24	Conduktor Console MCP	Documented. Built into self-hosted Console	Always read-only	The user’s own token permissions	Not stated	Nothing to approve	Up to 100 messages per call	Conduktor’s documentation, MCP page

How the options score

On read vs write scope, Aiven leads with a read-only flag plus an allowlist for single writes, and Lenses and StreamNative follow with scopes and a read-only mode. Conduktor and WarpStream are read-only with no way to write. mcp-confluent, Google Cloud’s server and the community servers register delete tools with no read-only switch.

On the permission model, Lenses is the most explicit, with OAuth 2.1 read, write and delete scopes validated by the platform behind it. Conduktor, WarpStream and Confluent’s managed server run as a specific user or scoped key. Every community server runs as one Kafka principal.

On audit, Confluent’s managed server is the clear leader: each tool call is written to the Confluent Cloud audit log with the principal that made it. kafka-sentinel-mcp logs every call locally. Most others say nothing.

On approval and on message exposure, the field is weak across the board. Kpow is the exception on approval, because an RBAC policy carrying the Stage effect holds a mutation until an administrator approves or denies it, though Factor House does not state how that applies to each MCP tool. No server on this page documents masking of records before they reach the model, Kpow included: its data policies redact fields server-side before results leave Kpow, and how that applies to MCP tool output is not published. The KIP-1318 reference code redacts PII on its consume path, and the proposer describes it as an in-memory reference, not production software. The practical answers today are servers with no record-reading tools (Google Cloud, WarpStream, the Kubernetes route) or ones where you can leave the consume tools out (StreamNative).

On cost the figures are our own model rather than a vendor quote, and the shape of the answer matters more than the arithmetic. Kpow is the only option here with a complete published total: $13,500 of licence for three clusters plus $2,880 of run time, $16,380 a year. The servers that charge nothing are not cheaper once the engineer-hours are counted, because a self-hosted server credentialed against three clusters runs to $14,400 a year on its own, and a server with no tool-call audit adds a 40-hour incident reconstruction the first time somebody asks what the agent did. That puts mcp-confluent and the community servers at $24,480, StreamNative and Kafbat UI’s endpoint at $21,600, and shell access at $19,200. Conduktor Console MCP is the highest at $127,680, because Team Edition is a published $1,200 a seat and 100 engineers is 100 seats. The hosted vendor servers look cheapest at $2,880 to $7,680 of time, and those totals are incomplete: the subscription underneath is billed on usage rather than published as an annual number, so it cannot be set beside Kpow’s.

On totals out of 60, Kpow leads at 36, followed by Confluent’s managed server (33), WarpStream (32), kafka-sentinel-mcp (31) and KIP-1318 (30). Conduktor Console MCP prints 26 and still sits last, because we place it last on every comparison page whatever its total. The cards below list Kpow first because it is our product, which here matches its score as well, then every other option in score order. The totals printed on the cards are unadjusted.

Kpow’s strength is the layer under the tool list. It scores 7 on the permission model and 6 on approval, because RBAC can already allow, deny or stage each action and the demo states agentic users inherit it, and 9 on availability and cost, because the server is generally available, runs wherever Kpow runs against any cluster Kpow connects to, and carries the lowest complete annual total on the page. It scores 5 on scope, 5 on audit and 4 on message exposure, because the tool list is not published and neither is a statement of how masking and the audit log apply to each tool, for a total of 36.

1. Kpow

The Kpow MCP server ships with version 2 of the Kpow API, alongside the fh command-line interface, the terminal UI and the agent skills that drive the CLI. In the September 2026 demo I walked through the order the pieces arrive in, the CLI and terminal UI first and then the API and MCP, and the reason OpenID Connect sits under all of them: “if you want to use MCP, you have to use OIDC or OAuth 2”. What Factor House has not published is the tool list, which is why three cells above read that they are not stated.

2. Confluent managed MCP

Confluent hosts the server. It lists environments, clusters and topics, reads connector status, logs and metrics, summarises connector errors, reads schema subjects, and samples up to ten messages. Confluent’s documentation, Managed MCP server page, is the source.

3. WarpStream Console MCP

Exposes WarpStream’s control plane: virtual clusters, topics, diagnostics, events, ACL checks, pipelines and consumer group lag. WarpStream’s documentation, MCP server page, is the source.

4. Conduktor Console MCP

Lists clusters, topics with usage, consumer groups with lag, schema subject names, Gateway interceptors and Insights health data, and reads the last N messages of a topic. Conduktor’s documentation, MCP page, is the source.

5. Lenses MCP

Topics, partitions, consumer groups, connectors, SQL processors and Lenses SQL over topic data, with writes that include creating topics, updating topic config, deleting connectors and deleting consumer group offsets. Tool list from the lensesio/lenses-mcp README and Lenses’ documentation.

6. kafka-sentinel-mcp

Cluster health, consumer lag, topic audit, partition state, replay readiness and incident snapshots, all read-only. Source: the kafka-sentinel-mcp README.

7. KIP-1318

A first-party MCP server for Apache Kafka, with OAuth 2.1, topic scoping, a separation between reading data and changing the cluster, and a tamper-evident audit trail. The proposer’s reference implementation is “a stdio, in-memory conformance reference”, not connected to real brokers.

8. Aiven MCP

Aiven projects, services, logs and metrics, Kafka topics, message reads, connectors and Schema Registry, with writes that include topic delete, message produce and connector delete. Source: the mcp-aiven README.

9. Google Cloud Managed Kafka MCP

Creates, updates and deletes Managed Kafka clusters, topics, consumer groups, ACL entries, Connect clusters and connectors through https://managedkafka.googleapis.com/mcp. Source: the MCP tools reference.

10. Kubernetes and Strimzi MCP servers

Operate Kafka through Kubernetes objects. The generic kubernetes-mcp-server treats Strimzi resources as any other custom resource. Strimzi Kafka CLI and strimzi-mcp-server add Kafka-aware tools, and StreamsHub MCP targets read-only diagnostics.

11. StreamNative MCP

Kafka admin for topics, partitions, groups, Schema Registry and Connect, plus produce and consume, and Pulsar tools. Source: the streamnative-mcp-server README.

12. Shell access to the Kafka CLI

The agent runs the same commands you would, through its shell tool: kafka-topics.sh, kafka-consumer-groups.sh, kcat or kcl.

13. Kafbat UI MCP

Set mcp.enabled: true and Kafbat UI exposes tools generated from its own API controllers. Source: the Kafbat MCP documentation and its source code. The UI underneath it is scored against the other consoles that cost nothing in the best free Kafka UI tools, which is worth reading before you adopt one for the endpoint alone.

14. Redpanda Cloud MCP

Wraps Redpanda Cloud’s control plane and data plane APIs for clusters, topics and users, run locally through rpk. Redpanda’s documentation, Cloud MCP pages, is the source.

15. mcp-confluent

More than 50 tools across Kafka, Schema Registry, Connect, Flink and Tableflow, including create-topics, delete-topics and produce-message. Against self-managed Kafka only the Kafka and Schema Registry tools are enabled. Source: the mcp-confluent README.

16. Other community Kafka MCP servers

Topic listing, consume, produce and consumer group tools over one Kafka connection: tuannvm/kafka-mcp-server, kanapuli/mcp-kafka, pavanjava/kafka_mcp_server, wklee610/kafka-mcp, gAmUssA/mcp-kafka and, for Schema Registry, aywengo/kafka-schema-reg-mcp.

Vendor MCP servers: which environment each fits

Match the server to where your Kafka runs first, because most vendor servers only manage their own platform.

• Confluent Cloud: the managed server for diagnosis, with the best audit trail in the field. Use mcp-confluent only with an allowlist.
• Google Cloud Managed Service for Apache Kafka: Google’s remote server manages infrastructure without reading records. Narrow its IAM role, since the setup page asks for admin.
• Aiven: the Aiven server with read_only=true, adding writes one at a time through the allowlist.
• Lenses or Conduktor users: the server built into the platform you already run, which inherits its identity model.
• WarpStream or Redpanda Cloud: the vendor server, with Redpanda’s beta label in mind.
• Self-managed Apache Kafka, Amazon MSK or anything else: StreamNative’s server in read-only mode, Kafbat UI’s endpoint if you already run Kafbat, or a dedicated read-only principal behind whichever server you pick.

Community open-source servers: the trade-offs

Community servers are easy to read and quick to run, and each one is a thin wrapper over a single Kafka connection. That makes the Kafka principal in its config file the whole permission model. If you use one, give it a principal with Describe-only ACLs, pin it to a commit you have read, and treat a README claim of “production safety” as something to test, not accept. kafka-sentinel-mcp is the pattern worth copying: read-only enforced in code, every call logged.

The same logic applies to the Strimzi and Kubernetes route. Kubernetes RBAC is a strong permission model, but servers such as strimzi-mcp-server include restart_kafka_broker, and a ServiceAccount that can patch Strimzi resources can do a lot of damage through one custom resource.

How Factor House approaches Kafka MCP

Kpow’s approach is to give agents the same interface engineers use, and the same controls over it.

There are four pieces and they share one access path. fh, the Factor House command-line interface, is version 0.8.0 in Factor House’s Homebrew tap and reaches almost everything the Kpow web application does, with no consume or produce command in its published command tree. The terminal UI ships inside the same binary. The agent skills demonstrated in September 2026 with Claude drive that CLI. The MCP server comes with version 2 of the Kpow API. How skills and MCP servers differ as ways to give an agent cluster access is covered in Kafka agent skills compared.

What carries across all three is governance. In the demo I put it this way: “your CLI users, terminal UI users, and agentic users all get the same control and governance in place.” In practice that means:

• the agent signs in through your OpenID Connect provider, not a shared key, as covered in Kafka SSO tools
• Kpow RBAC allows, denies or stages each action per cluster, topic, group, connector or schema subject
• a staged mutation waits for an admin to approve or deny it, and the fh CLI reports “Mutation staged for admin approval” rather than failing silently
• the audit log records who made each request and what it contained, and its webhook payload marks whether it came through the API or the UI
• data policies redact fields server-side before results leave Kpow, per the Kpow governance page

These controls are Enterprise features. What Factor House has not yet published is the MCP tool list, or how masking and audit apply to MCP tool calls specifically, which is why those cells read “not stated” above.

Kpow live demo

Watch an AI assistant diagnose Kafka through Kpow

See Claude work through failing connectors and a consumer that looks stuck, using Kpow's CLI under the same SSO and RBAC as the web UI.

Built for platform and data engineers running Kafka in production.

Watch the demo→

How to connect one to Claude

Most servers are added the same way: a command and arguments in the client’s MCP config. The part that matters is the flags. This example runs StreamNative’s server against a self-managed cluster in read-only mode, with only the admin toolsets enabled, so the produce and consume tools are never registered:

{
  "mcpServers": {
    "kafka-readonly": {
      "command": "/usr/local/bin/snmcp",
      "args": [
        "stdio",
        "--use-external-kafka",
        "--kafka-bootstrap-servers", "broker1:9093",
        "--kafka-auth-type", "SASL_SSL",
        "--kafka-auth-mechanism", "PLAIN",
        "--kafka-auth-user", "agent-diagnostics",
        "--kafka-auth-pass", "<from your secret store>",
        "--kafka-use-tls",
        "--read-only",
        "--features", "kafka-admin"
      ]
    }
  }
}

Whatever server you pick, check its equivalent before connecting it to production:

• a read-only switch: --read-only (StreamNative), read_only=true (Aiven), the read scope (Lenses), read_only: true (kubernetes-mcp-server)
• a delete gate: --allow-delete off (Redpanda Cloud), --block-tools delete-topics (mcp-confluent)
• the credential it runs as, which should be a principal created for the agent and nothing else

Choosing the server is half the job. Setting up the principal, the ACLs, the approval step and the audit trail is covered step by step in how to let an AI agent operate Kafka safely.

Which one to choose

For diagnosis on Confluent Cloud, the managed server, because its audit trail is the best documented. For diagnosis anywhere else, a read-only server with no consume tools, running as a Describe-only principal. If the platform underneath is still open, the roundups of Kafka management tools and Kafka monitoring tools score the same products on the work an engineer does by hand, which is the surface an agent inherits. If you need writes, choose a server with scoped write permissions (Lenses, Aiven’s allowlist) and put the approval step in the platform rather than in the prompt, since no MCP server on this list documents one.

If you already run Kpow Enterprise, the MCP server and the fh CLI both work under the RBAC, staged mutations, tenancy and audit log you already have, so the evaluation is the tool list rather than the identity model. On our model that is $16,380 a year for three clusters, against $16,800 to $24,480 for a server that charges nothing and leaves you to run it, write its ACLs and reconstruct what it did.

FAQ

What is a Kafka MCP server?

A Kafka MCP server exposes Kafka operations, such as listing topics, reading consumer lag or creating a topic, as tools an AI assistant calls through the Model Context Protocol. It connects to the cluster with a credential, so its safety depends on whose credential that is and what it is allowed to do.

What makes a good Kafka MCP server?

It runs read-only by default, acts as a specific identity with server-side permissions, records every tool call with that identity, and keeps message contents out of the model unless you opt in. No server on the market today does all four, so pick the one closest to your platform and fill the gaps with Kafka ACLs and platform-side approval.

How much does it cost to run a Kafka MCP server?

Nothing here is free once the engineer-hours are counted. On our own model, three Kafka clusters and engineering time at $120 an hour, a self-hosted community server runs to about $14,400 a year in run time alone, and more where you also write the ACLs it does not enforce, read and pin each release yourself, or rebuild what the agent did from broker logs because no tool call was logged: $24,480 a year for mcp-confluent and the community servers, $21,600 for StreamNative and Kafbat UI’s endpoint, $19,200 for shell access. A server the vendor hosts costs $2,880 to $7,680 of time, plus a platform subscription billed on usage rather than published as an annual figure. Kpow’s total is $16,380, the published $4,500 per cluster for three clusters plus $2,880 of run time. Model tokens sit on top of every one of these, and the servers that read messages send the most.

Can a Kafka MCP server run in read-only mode?

Several can. StreamNative has --read-only, Aiven has read_only=true, Lenses grants a read scope, and Conduktor and WarpStream are always read-only. For any server without a switch, give it a Kafka principal with Describe-only ACLs, and the broker refuses writes whatever the server attempts.

Related reading

• Kafka: the complete guide
• How to let an AI agent operate Kafka safely
• Kafka ACL
• How to find and mask PII in Kafka topics
• Best tools for Kafka audit logging
• RBAC roles