Your AI already knows Kafka. Now it knows yours.
Connect Claude, Cursor or any AI assistant to every cluster you run. Ask what changed, why a consumer is stuck, who can read what, and what it all costs. The answers come from your live Kafka.
Try asking
Prepare our quarterly access review: who can read topics labelled pii, how they got that access, and which grants nobody owns.
- Found every topic labelled pii, on every cluster
- Listed the ACLs on each one
- Matched each principal to an application and an owner
- Checked the audit log for recent grant changes
23 principals can read at least one of your 14 PII topics. Most go through their own team's prefix, as expected. Two don't:
| Principal | Reads | Through | Owner |
|---|---|---|---|
| analytics-etl | every topic | wildcard grant | none |
| legacy-batch | every topic | ALL on the cluster | none |
legacy-batch's grant was widened on September 12 by ops-admin. Want the full review as a table for your auditors?
We're shutting down kafka-eu-old at the end of the month. What still depends on it, and who do I need to talk to?
- Listed its topics and their traffic
- Found the consumer groups still reading
- Checked the connectors that use it
- Matched everything to applications and owners
Most of it is already dead: 212 of its 240 topics have no traffic and no consumers. Four teams still depend on the rest.
| Team | Still running | Next step |
|---|---|---|
| risk | fraud-scoring reads 3 topics | Migrate first, it's tier-1 |
| orders | 2 consumer groups on orders.v1 | Move to orders.v2 |
| data-platform | s3-archive-sink | Repoint the connector |
| no owner | 26 topics with live traffic | Find who produces them |
Start with risk. The 26 unowned topics are the real unknown: the service accounts writing to them don't belong to any application.
Three connectors on prod-eu started failing overnight. What happened?
- Listed the failing connectors and their errors
- Checked what Connect is allowed to read
- Searched the audit log for overnight changes
All three fail with the same error: Connect is no longer allowed to read their topics.
At 02:47, ops-admin removed the prefixed ACL on orders. during a cleanup. That one grant covered all three sinks: orders.created, orders.updated and orders.refunds.
Restore it and all three recover. It was probably meant to replace the literal grants removed in the same change.
checkout-service has been lagging since this morning's deploy. Is it my code, the schema or the cluster?
- Read checkout-service's offsets and lag
- Checked the cluster and its partitions
- Opened the record it's stuck on
- Went through the schema's history
It's not your deploy, it's the schema. The cluster is healthy, and only partition 3 is stuck, on a single record.
That record was written with version 7 of orders-value, registered at 08:55 by the orders team. Version 7 renamed customer_id to customerId, and checkout-service fails on it. The subject's compatibility is set to NONE, so the registry let it through.
Update checkout-service to read customerId, or ask the orders team to roll the change back.
I'm building a fraud service. Where do I get payment events, who owns them, and what do I need to read them?
- Searched the catalog for payment topics
- Read the best match's schema and traffic
- Found the application that owns it
- Checked what your team can already read
Use payments.transactions: every authorized payment, in Avro, around 1,800 messages a second.
It belongs to payments-core, owned by team-payments. It's labelled pii, so reading it needs their approval.
Your team doesn't have access yet. Request it from payments-core in Console. fraud-detection already reads payments.refunds through the same flow, so it should be routine.
I'm adding loyalty_tier to user-events. Will the new schema break anyone, and who should I warn?
- Tested the new schema against the registry
- Found every consumer group on user-events
- Matched them to applications and owners
As written, the registry would reject it: the subject is BACKWARD compatible and loyalty_tier has no default. Add one and it passes.
Three teams read user-events: crm with crm-sync, notifications, and risk with fraud-scoring. Warn risk first: fraud-scoring is labelled tier-1.
One assistant for the team that runs Kafka, and every team that builds on it
If Console can see it, your assistant can explain it, to whoever is allowed to ask.
Platform teams
Run the whole estate from one conversation
The questions that used to mean a spreadsheet and a long Slack thread: who can read what, what a change would break, where the money goes.
- Access reviews ready for your auditors
- Cluster retirements without surprises
- Incidents traced across connectors, ACLs and the audit log
- Kafka cost broken down by team
Application teams
Answers about your apps, no ticket needed
Ask about your own topics, consumers and schemas from your editor, while you work. The platform team stops being the help desk.
- Why your consumer is stuck, and on which record
- Whether a schema change breaks anyone
- Where the data you need lives, and how to get access
- What changed around your app since the last deploy
It only knows what you're allowed to know.
MCP runs inside your Console, under the permissions you already manage. Follow one question through it.
Inside your Console, in your network
"Which topics hold customer data?"
Asked by a platform admin
14 topics on prod-eu and prod-us, owned by five teams.
Asked by a developer on team-payments
3 topics, all owned by your team.
Same assistant, same question. The answer depends on who is asking.
Nothing new to deploy or trust
MCP is part of the Console you already run. No extra service, and no Conduktor cloud in the path.
The model you approved
Your assistant talks to your model. Conduktor sends nothing to any AI provider.
Off with one setting
Turn MCP off for everyone with enable_mcp: false.
Before connecting an agent, ask our website AI about MCP permissions and data access.
Ask your first question in two minutes
Create a personal token in Console, paste one config into your assistant, and ask.
claude mcp add --transport http conduktor \ https://console.acme-corp.com/api/mcp \ --header "Authorization: Bearer <token>"
{
"mcpServers": {
"conduktor": {
"url": "https://console.acme-corp.com/api/mcp",
"headers": { "Authorization": "Bearer <token>" }
}
}
} {
"servers": {
"conduktor": {
"type": "http",
"url": "https://console.acme-corp.com/api/mcp",
"headers": { "Authorization": "Bearer <token>" }
}
}
} {
"mcpServers": {
"conduktor": {
"command": "npx",
"args": ["-y", "@conduktor/mcp"],
"env": {
"CONDUKTOR_CONSOLE_URL": "https://console.acme-corp.com",
"CONDUKTOR_API_TOKEN": "<token>"
}
}
}
} Use your Console URL, and a Personal Access Token from Settings > API Keys. Any other MCP client works the same way. Setup guide →
Want it to make changes too? Give your agent Conduktor Skills →
Copied to clipboard
Where does my data go?
Answers go to the assistant that asked, and to the model it uses. Conduktor sends nothing anywhere else. Most answers are built from metadata. Your assistant only reads message contents when a question needs them, and only from topics you can read.
What can the assistant see?
Exactly what you can see in Console. It connects with a personal token that carries your own permissions.
Can it change anything?
It can label topics, if your permissions allow it. Everything else is read-only. For bigger changes, pair it with Conduktor Skills and the CLI.
Which assistants work with it?
Claude Code, Claude Desktop, Cursor, VS Code, and any client that speaks MCP. Conduktor MCP is listed on the GitHub MCP Registry and the official MCP Registry.
Can we turn it off?
Yes. Revoke a token in Settings > API Keys and it stops on the next call, or set enable_mcp: false to remove MCP for everyone.
See it on your own Kafka
Book a demo and we'll connect MCP to a live environment, then ask the questions your team asks every week.