I Want to Use MCP with Kafka. Which MCP Servers Exist?

"I want to use MCP with Kafka. Which MCP servers exist?"

Most answers to that question are a list of repositories, as if every Kafka MCP server did the same job and you only had to pick one. They don't. A Model Context Protocol server gives an AI assistant a set of tools to call, and two choices made by whoever built it decide what those tools are good for: what the server connects to, and whose permissions it uses when the assistant calls a tool.

Here are the options we know of, as of October 2026:

Server	Connects to	Whose permissions	Changes it can make
Conduktor Console (built in, free tier)	Every cluster Console manages, plus Schema Registry, Kafka Connect, ACLs, the audit log and chargeback	The caller's personal token, with Console RBAC and masking applied	Topic labels; other changes go through the CLI
Confluent MCP server	Confluent Cloud and its APIs	—	—
Redpanda, through rpk	Redpanda Cloud	—	—
Kafbat UI (Apache 2.0)	The clusters configured in Kafbat UI	—	—
Lenses	The clusters managed in Lenses	—	—
Open-source servers that talk to the brokers	A cluster, through a Kafka client config	The credential in that config	Whatever the server exposes
AKHQ	No MCP server	—	—

A note on the dashes. A dash means we couldn't confirm the detail in the vendor's own docs, not that the feature is missing. This is Conduktor's blog, so check each vendor's docs before you decide.

A Kafka MCP server decides what your assistant can see

MCP is a protocol between an assistant and a server. An assistant like Claude, Cursor or VS Code Copilot connects to the server, reads the list of tools it offers, and calls one when a question needs it. The server runs the call and returns the result, which then goes into the model's context.

So the server decides which questions have an answer, because a question about something it can't reach gets a guess. It also decides what the assistant may see, because every tool call runs with the server's credential.

Take a developer on the payments team who asks their assistant, "Which topics does my team own, and which of them have gone stale?" Three kinds of server can sit behind that assistant:

Only the bottom server can answer the ownership half of the question without guessing.

Where the server connects decides what it can answer

A server that talks to the brokers can list topics, partitions, configs, consumer groups and offsets, because that's what the brokers store. Kafka doesn't store who owns a topic, what it costs, or who changed its retention last week. So that server can count the payments topics nobody has read in a while, but it can't tell which ones belong to the payments team unless the topic names happen to say so.

A vendor's cloud server is built around that vendor's platform and its APIs. It stops at the edge of that platform, which is fine if all your Kafka runs there.

A management layer already holds the metadata the brokers don't, so its MCP server can answer both halves of the question. Conduktor Console works this way. Its MCP server is part of Console, so there's nothing extra to deploy, and it reaches every cluster Console manages and the metadata Console keeps about them:

• Ownership and lineage. list-applications shows which application owns what, and get-stream-lineage shows who's allowed to write to and read from a topic, derived from ACLs.
• Change history. query-audit-log answers who changed what, on which resource, and when.
• Cost and cleanup. get-chargeback-report returns cost per application, and aggregate-topics counts stale topics per team, so the assistant gets totals instead of thousands of topic rows.
• Troubleshooting. Lag per partition, failed connector tasks with their errors, and a Schema Registry compatibility check before a schema is registered.

Troubleshooting comes up a lot in the conversations we have with platform teams. An engineer on call wants the assistant to answer from the live cluster, not from internal documentation that may be two years out of date.

Whose permissions it uses matters more than its tool list

For a dev cluster on your laptop, a server with one credential in its config file is fine. You're the only user, and the credential is yours.

On a shared cluster, the same setup means every person who connects an assistant gets the server's view. If that credential belongs to a service account that can read every topic, a developer's assistant can read every topic, including ones that developer couldn't open in any UI. The ACLs and the broker logs also record the service account, not the person who asked.

Platform teams we talk to are wary of exactly this. Some have told us they're setting rules for which teams can use which MCP servers, because they don't want servers with broad access showing up in every team before anyone has looked at them.

Conduktor's MCP server takes the other approach for people. Each request carries the caller's personal access token, Console RBAC filters every answer, and fields masked for that person in Console stay masked for their assistant. Revoke the token and the next call fails:

Neither person needed a new credential to get their answer, and the platform team didn't write a second set of permissions for assistants. When a person is driving, the person's identity is the right one. An automation that runs on its own should get an identity of its own.

Reading Kafka data isn't harmless

Most Kafka MCP servers start with tools that read, and that's a sensible place to start. But on Kafka, reading includes reading messages.

🚫 "It only reads, so any MCP server is safe to connect."

Whatever a tool returns goes into the model's context. A tool that fetches the last ten messages on payments sends ten payment records to whichever model your assistant uses. So before you connect any server to a shared cluster, find out whether it can read message contents and whether anything masks sensitive fields first.

In Conduktor, get-last-messages and get-record-at return records with the same masking the caller gets in Console. Admins can also turn the MCP server off for everyone with enable_mcp: false, or revoke one person's token in Settings > API Keys.

Write access comes one action at a time

We recommend starting with read access, which our MCP server allows: apart from adding labels to a topic, every tool it offers reads. Write access is the next step, granted one action at a time, and each change should be something a person can read before it lands.

For changes, Conduktor Skills give a coding agent such as Claude Code, Cursor or Gemini CLI the steps for driving the Conduktor CLI. A change then goes through four commands:

Step	Command	What happens
Discover	conduktor get	The agent reads what's on the cluster before it generates anything
Generate	conduktor template <kind>	The CLI emits a YAML template, so the agent fills in known fields instead of inventing them
Check	conduktor apply --dry-run	The change is validated, and a policy violation shows up before anything is applied
Apply	conduktor apply -f	The change is applied after a person approves it

In a Git workflow, each change is a pull request and the dry run runs as a CI check.

What Conduktor's MCP server doesn't do

A few honest notes:

• It needs Console. The server is part of Console, so it covers the clusters Console manages. Some tools, such as aggregate-topics and query-topics, also need Insights enabled.
• The model still does the interpreting. Conduktor returns the data, but how an assistant reads it depends on the model, and that's outside Conduktor's control.

Which MCP server should you pick?

Start from where your Kafka runs and who will connect, because the server's reach and identity follow from those:

• Trying MCP by yourself on a dev cluster. An open-source server that talks to the brokers is quick to set up, and its single credential is yours anyway. Keep it away from shared clusters.
• All your Kafka is on Confluent Cloud or Redpanda Cloud. Start with your vendor's server, since it's built for that platform. Check whose permissions it uses before you hand it to other teams.
• Already running Kafbat UI or Lenses. Try the MCP server that comes with the UI you know, and check the same two things: what it can read, and under whose identity.
• Many teams, several clusters, and data that needs protecting. Conduktor Console gives each person's assistant their own view through their own token, across every cluster Console manages, with ownership, audit history and costs in reach. It's included in Console Community, which is free for up to 50 users and 3 clusters.

Which MCP servers exist matters less than two properties of the one you connect: what it can reach, and whose permissions it uses. A server with one shared credential is fine for one person on a dev cluster. On a cluster that fifty teams share, the assistant should see what the person asking can see, and nothing more.

---

Related: Conduktor MCP + Skills for AI Agents → · Kafka AI Agents Should Behave Like Kubernetes Controllers → · Kafka MCP Server →