Conduktor
Read-only Kafka access for AI assistants: topics, consumer groups, schemas, cluster health.
Install
Add this to your client's MCP configuration (Claude Desktop: claude_desktop_config.json; Cursor: .cursor/mcp.json; VS Code and others use the same "mcpServers" shape).
claude mcp add --transport http conduktor 'https://{console_host}/api/mcp' --header 'Authorization: <Authorization>'{
"mcpServers": {
"conduktor": {
"type": "http",
"url": "https://{console_host}/api/mcp",
"headers": {
"Authorization": "<Authorization>"
}
}
}
}@conduktor/mcpclaude mcp add conduktor -e 'CONDUKTOR_CONSOLE_URL=<CONDUKTOR_CONSOLE_URL>' -e 'CONDUKTOR_API_TOKEN=<your conduktor_api_token>' -- npx -y @conduktor/mcp@1.0.0{
"mcpServers": {
"conduktor": {
"command": "npx",
"args": [
"-y",
"@conduktor/mcp@1.0.0"
],
"env": {
"CONDUKTOR_CONSOLE_URL": "<CONDUKTOR_CONSOLE_URL>",
"CONDUKTOR_API_TOKEN": "<your conduktor_api_token>"
}
}
}
}Environment variables
CONDUKTOR_CONSOLE_URLrequired Your Conduktor Console base URL, e.g. https://console.acme-corp.comCONDUKTOR_API_TOKENrequired secret Personal Access Token created in Conduktor Console
Documentation
From the project's README on GitHub, refreshed weekly. Links open on GitHub.
Contents
Conduktor MCP
Put an AI assistant in charge of your Kafka estate.
Not a chat window onto a cluster. A way for agents — yours, or ours — to see what is actually happening across every cluster you run, and to act on it: reclaim the topics nobody consumes, attribute cost back to the teams spending it, catch the certificate expiring next month, restart the connector that failed at 3am, label the topics whose owner left the company.
The MCP endpoint ships inside Conduktor Console. There is nothing to deploy, and nothing new to secure: the assistant inherits the RBAC, audit trail and ownership model you already run.
Try it first
No Kafka to hand? demo/ brings up a cluster, Console and the MCP endpoint with
docker compose up -d, seeded with topics, traffic and a consumer group that is deliberately
behind.
Setup
Create a Personal Access Token in Console, then point your MCP client at your own Console:
{
"mcpServers": {
"conduktor": {
"command": "npx",
"args": ["-y", "@conduktor/mcp"],
"env": {
"CONDUKTOR_CONSOLE_URL": "https://console.acme-corp.com",
"CONDUKTOR_API_TOKEN": "your-personal-access-token"
}
}
}
}/api/mcp is appended for you. Pasting a URL that already ends in it works too.
Connecting without the package
@conduktor/mcp wraps mcp-remote. Call it
yourself if you prefer:
{
"mcpServers": {
"conduktor": {
"command": "npx",
"args": [
"mcp-remote",
"https://console.acme-corp.com/api/mcp",
"--header",
"Authorization: Bearer ${CONDUKTOR_API_TOKEN}"
],
"env": { "CONDUKTOR_API_TOKEN": "your-personal-access-token" }
}
}
}What an assistant can ask
Ask in English, get answers grounded in your actual estate rather than in documentation:
Which topics haven't been consumed in a month, and who created them? What did the payments team cost us last quarter, and what drove it? This consumer group is stuck — what's the blocking message? Which certificates expire before March, and whose are they? Nobody owns these topics. Can you work out who should, from the lineage?
Those are not demos. Each maps onto tools below, and onto tasks an agent can run unattended.
From answering to operating
The same catalogue serves two kinds of caller. Your tools — Claude Code, Cursor, scripts, your internal developer platform — and agents running inside Console, on a schedule or on an audit-log event, under their own machine identity.
That second one is where this stops being a chatbot. An agent is a task plus an identity plus a bounded set of tools. It wakes up on Monday at 9am, or the moment a connector fails, works the problem, and comes back with something you can act on — a report, a recommendation, or a mutation it proposes and you approve.
Every run is traced end to end: the prompt, each tool call, the tokens, the result. That is what you attach to a ticket, or hand to an auditor.
Tools
Thirty-one, across the whole control plane. Most read; some write, and that set is growing.
Clusters
| Tool | What it does |
|---|---|
list-clusters | Every Kafka cluster this Console manages, with its Schema Registry, Connect clusters and flavor |
get-cluster | One cluster's registration by slug |
insights-cluster | Health score, topic and partition counts, serialization breakdown — the shape of a cluster in one call |
Topics
| Tool | What it does |
|---|---|
list-topics | Topic catalogue: names, labels, descriptions, partitions, replication, configs |
get-topic | One topic by exact name |
list-topics-with-usage | Topics with message count, size and throughput |
query-topics | Filter topics across a cluster |
aggregate-topics | Group topics and compute a statistic per group — count, sum, average, min, max |
insights-topics | Partition skew, replication problems, and what is quietly wrong |
set-topic-labels (writes) | Label topics — ownership, environment, whatever your taxonomy is |
Messages
| Tool | What it does |
|---|---|
get-last-messages | The last N messages from a topic |
get-record-at | A specific record, by partition and offset — the one blocking a consumer |
Consumer groups
| Tool | What it does |
|---|---|
list-consumer-groups | Groups with state, lag and member count |
get-consumer-group | One group in detail |
list-consumer-groups-by-topic | Who actually reads this topic |
Schemas
| Tool | What it does |
|---|---|
list-subjects · get-subject · list-subject-names | The subject catalogue |
get-schema-version | A specific version |
check-schema-compatibility | Whether a change breaks consumers, before it ships |
Connect, Gateway
| Tool | What it does |
|---|---|
list-connectors-detailed · get-connector | Connectors and their state |
list-interceptors | Gateway interceptors configured on a cluster |
Access, identity, governance, cost
| Tool | What it does |
|---|---|
list-acl-bindings | Who is allowed to do what |
list-service-accounts · get-service-account | Non-human identities |
list-certificates | Certificates and their expiry |
list-applications | Applications registered in the catalogue |
get-stream-lineage | What flows into what |
query-audit-log | Who did what, when |
get-chargeback-report | Cost attributed per team |
Security is what makes this possible
Giving an agent real access to production is only reasonable because the boundaries already exist and are enforced per call.
It is you. Every call carries a Console token and runs under that user's RBAC. An agent cannot see a cluster its owner cannot see. Revoke the owner's access and the agent loses it at the same instant.
Control plane, not data plane. What reaches the model is metadata — topics, configs, offsets, groups, schemas, lineage, cost. Your records stay in Kafka unless a task explicitly needs a tool that reads them.
Everything is audited. Every call lands in the Console audit log, attributable to the identity that made it.
Documentation
What is in this repository
The launcher published as @conduktor/mcp, this
documentation, and the registry metadata. The server itself runs inside Console. For bugs in the
server use Conduktor support; for the launcher or these docs, open an issue here.
Frequently asked questions
What is Conduktor?
Read-only Kafka access for AI assistants: topics, consumer groups, schemas, cluster health.
How do I install Conduktor?
It runs as a remote server. In Claude Code: claude mcp add --transport http conduktor 'https://{console_host}/api/mcp' --header 'Authorization: <Authorization>'. For other clients, paste the JSON configuration from this page into their MCP settings.
Does Conduktor need an API key?
Yes. It expects CONDUKTOR_CONSOLE_URL, CONDUKTOR_API_TOKEN, Authorization, which you set in its configuration.
Is Conduktor open source?
Yes. Its code is on GitHub under the Apache-2.0 license.
Who maintains Conduktor?
It is published by conduktor. AI.tn lists it but does not maintain or endorse it.
From the official MCP Registry. Listing is not an endorsement: review a server's code and permissions before giving it access to your data.