Hi all, I would like to share an update on KIP-1318 <https://cwiki.apache.org/confluence/spaces/KAFKA/pages/421953714/KIP-1318+Model+Context+Protocol+MCP+Server+for+Apache+Kafka> (Model Context Protocol server for Apache Kafka) and ask for feedback on the DISCUSS thread.
I fully understand the community's focus is on core data-plane work right now, so I have tried to make this easy to evaluate rather than adding to the queue. Standardizing how agents talk to Kafka is becoming timely: within the ASF, Apache Superset now ships an MCP server (SIP-187) and Apache Airflow has an official MCP connection type in its common-ai provider. My concern is that without a first-party, standardized interface, teams end up wiring brittle, bespoke LLM integrations that sit outside Kafka's security and rate-limiting model. https://vaquarkhan.github.io/kafka-mcp-enterprise-server/slides.html To make the design concrete and testable, I built a reference implementation. I want to be precise about its scope so it is judged fairly:It is a Python, standard-library, stdio, in-memory conformance reference for the KIP's security control model. It is a teaching and validation artifact, not the production server. The KIP's production target is Java, wrapping the native Admin/Producer/Consumer clients. Streamable HTTP, OAuth 2.1, EOS/fencing, Connect tools, distributed rate/breaker state, and durable audit topics are specified in the KIP and are the Java track. They are intentionally NOT implemented in this reference, and a conformance test asserts their absence so the docs cannot overclaim. What it does validate end to end: the fail-closed control pipeline, secure-by-default tool exposure (only read/non-destructive tools registered unless an operator opts in), topic/group scoping, taint guard, signed approval tokens, DLP and egress control, bounded output, per-module circuit breakers, and every JSON-RPC error code in the KIP. It ships with 302 automated checks (all passing via python run_tests.py) and six persona-based examples. On the architectural concerns around stability, the design keeps the MCP server as a standalone process outside the broker JVM, so agent query load cannot compete with broker request-handler threads. That failure-domain isolation is a design property I would genuinely like the PMC to poke at, along with the security boundaries and the schema/validation approach. I would be grateful if reviewers could try the reference and challenge the control model. I am very open to "this belongs elsewhere" or "not now" as answers, and equally happy to help shape the Java module if there is interest. Links: KIP: https://cwiki.apache.org/confluence/display/KAFKA/KIP-1318%3A+Model+Context+Protocol+%28MCP%29+Server+for+Apache+Kafka Jira: https://issues.apache.org/jira/browse/KAFKA-20436 Reference implementation (GitHub): https://github.com/vaquarkhan/kafka-mcp-enterprise-server Docs / site: https://github.com/vaquarkhan/kafka-mcp-enterprise-server/tree/main/doc https://vaquarkhan.github.io/kafka-mcp-enterprise-server/ Try it: pip install kafka-mcp-enterprise then python run_tests.py Thank you for your time and for the work you all put into Kafka. Regards, Viquar Khan https://www.linkedin.com/in/vaquar-khan-b695577/
