Skip to content

Proposal for donating streamshub-mcp to Strimzi org #11

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
Frawless wants to merge 1 commit into
base: main
Choose a base branch
from
Open

Proposal for donating streamshub-mcp to Strimzi org #11

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
66 changes: 66 additions & 0 deletions 003-donate-streamshub-mcp-to-strimzi.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,66 @@
# Donation of streamshub-mcp to the Strimzi Organization

This proposal seeks formal agreement from StreamsHub to donate the [streamshub-mcp](https://github.com/streamshub/streamshub-mcp) repository to the [Strimzi](https://github.com/strimzi) organization.

## Current situation

The streamshub-mcp project was created under the StreamsHub organization as described in [proposal 002](./002-streamshub-mcp-strimzi.md).
It provides a Model Context Protocol (MCP) server for managing and troubleshooting Strimzi-managed Apache Kafka clusters.
The repository contains the Strimzi MCP server application along with shared modules (`common`, `metrics-prometheus`, `loki-log-provider`).

## Motivation

- The Strimzi community has expressed interest in adopting the MCP server as part of the Strimzi ecosystem.

@tomncooper tomncooper Aug 3, 2026

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do you have any links to issues/comments/discussions for this interest?

@Frawless Frawless Aug 3, 2026

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There was discussion directly on StrimziCon where we had a presentation about MCP.

Then there are few messages on Strimzi slack
https://cloud-native.slack.com/archives/CMH3Q3SNP/p1781587329036659?thread_ts=1781263622.033449&cid=CMH3Q3SNP
https://cloud-native.slack.com/archives/CMH3Q3SNP/p1785425543644589

Also there were discussions between Strimzi maintainers around MCP server.

- The MCP server is Strimzi-specific tooling — hosting it under the Strimzi organization provides better alignment with its primary domain.

@tomncooper tomncooper Aug 3, 2026

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Its Strimzi specific right now, but that was only ever supposed to be the starting point. Like you say below, we were planning to add Kafka in the near future and potentially targeting other tools in future.

How will this donation effect the ability to integrate with other tools and provide a joined up solution for users of out stack?

@Frawless Frawless Aug 3, 2026

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's more question for upcoming Strimzi proposals. However, the common parts (common module, metrics-prometheus and logs-loki modules) will be released to maven central so Kafka MCP can use it and it doesn't matter where it will be hosted. I would like to have Kafka MCP next to Strimzi one as it will provide additional information that Strimzi will not collect through Kafka Admin API. I think this Kafka MCP server could be run also as a standalone application, not just on OpenShift (similar to Kafka Bridge).

- Moving the project under Strimzi opens it to a broader contributor base and tighter integration with Strimzi's development and release processes.

## Proposal

The entire `streamshub-mcp` repository, including all modules (`common`, `metrics-prometheus`, `loki-log-provider`, `strimzi-mcp`, `systemtest`), will be transferred to the Strimzi GitHub organization.

The donation is subject to the following conditions:

### Availability

All released components of MCP servers within Strimzi org has to be publicly available.
The destination may differ based on what Strimzi will be using for their artifacts (`quay.io` vs `ghcr.io` for example), but it has to be available for anyone.
Any upcoming features, improvements, or code changes has to be public as well.

### Write access

David Kornel must be granted component owner to the donated repository.
Jakub Stejskal is already a Strimzi maintainer and requires no additional access.

### Modules reusability

The following modules - `streamshub-mcp-common`, `metrics-prometheus`, `loki-log-provider` - must be published to Maven Central so that modules can be used by external consumers without needing to build from source or fork the Strimzi repository.

### Pluggable interfaces

The following pluggable interfaces must remain as extensible SPI/CDI contracts, allowing alternative implementations to be provided without forking:

- **Metrics** — `MetricsProvider` interface with provider selection via `mcp.metrics.provider` configuration.
- **Logs** — `LogCollectorProvider` interface with provider selection via `mcp.log.provider` configuration.
Comment on lines +42 to +43

@MikeEdgar MikeEdgar Aug 3, 2026

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not familiar enough with specifically these do, but quickly looking at them I wonder if these metrics and log collector interfaces/providers would be good candidates as their own stand-alone components? I suppose that would complicate the process of moving the MCP server though.

@kornys kornys Aug 3, 2026

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

interfaces are part of common module, and both providers are planned to be released as standalone packages. I think it is written few lines forward.

@Frawless Frawless Aug 3, 2026

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, we just do not plan to have them in separated repository for now, but this might change in the future.

- **Auth** — currently not implemented, but users has to have option to replace auth & authz mechanism with their own implementation.

@tomncooper tomncooper Aug 3, 2026

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

On the AuthZ front, I was hoping we could standardise on a common Authorizer API for our components (potentially the one provided by Kroxylicious - details in #5). The reason I bring that up is that, subject to my upcoming proposal on this, it would be good to have the StreamsHub MCP use this API (whatever it ends up being) so it can be integrated easily with all the other StreamsHub components.

I worry that once it is donated to Strimzi, it might be hard to get a unified AuthZ approach (that aligns with StreamsHub's goals) included. To put it frankly, it would be easier if we made those changes before we donated, so they are baked in.

Maybe this is not such an issue for the Strimzi MCP (as it uses K8s RBAC for AuthZ) but it would be for the Kafka and other potential MCPs. Indeed, that might be an argument for developing them in StreamsHub rather than Strimzi.

@Frawless Frawless Aug 3, 2026

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This might be a valid concern, but as long as the Authorizer API will be in separated module with zero external dependencies as it stated in the issue, I do not see it as a big problem to use it even after moving MCP to Strimzi.

We have couple of options:

  • continue with donating efforts and use it for authz within Strimzi org (argument for using it could be that Apicurio Registry, another CNCF project, is going to use it as well which will enhance the UX)
  • postpone the donation until Authorizer API proposal and implementation will be merged and we can implement it in our MCPs (currently we do not use any authz mechanism as you mentioned so I do think we should go this way, we don't know how Kafka MCP will look like and it will require separated proposal wherver it will land)
  • stop the donation and wait couple of months to see if there will be more demands from Strimzi or StreamsHub communities and meanwhile implement whatever we will need

Even for Strimzi MCP we will probably need it at some point, because from my POV we will need to implement Kubernetes impersonation and make it able to work together with external oauth servers like Keycloak. So the question is if we want to stop it for not sure how long or simply move the code, benefit from wider Strimzi community and possibly direct Strimzi integration.

@Frawless Frawless Aug 7, 2026

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This can be also stated in the Strimzi proposal that we would like to adopt Authorizer API interface at some point.

- **Guardrails** — `GuardrailFilter` interface for request/response filtering (input validation, rate limiting, log redaction, response size limits).

### Kafka MCP server

There is a plan to develop a Kafka MCP server providing direct access to Apache Kafka internals (topics, consumer groups, broker configuration).
Whether this server will live alongside the Strimzi MCP server in the donated repository or remain in StreamsHub will be subject to further discussion with the Strimzi community.

## Affected/not affected projects

### Affected

- [streamshub-mcp](https://github.com/streamshub/streamshub-mcp) — transferred to the Strimzi organization.
- [streamshub-site](https://github.com/streamshub/streamshub-site) - all upcoming releases will be done in Strimzi org and release page will be eventually hosted on Strimzi website.

### Not affected

- All other StreamsHub projects remain unchanged.

## Compatibility

Existing users of the MCP server are not affected.

@tomncooper tomncooper Aug 3, 2026

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

At all? Won't the image addresses and package names change?

@Frawless Frawless Aug 3, 2026

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Well yes, they will need to update at some point to newer images with different paths where packages will be named differently. I didn't consider this as a problem, but I am happy to mention it there. Do you have any specific parts that should be mentioned?

The MCP protocol contract and Kubernetes API interactions remain the same regardless of which GitHub organization hosts the source code.
1 change: 1 addition & 0 deletions README.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -15,4 +15,5 @@ File name format and numbering is validated by the CI workflow defined in [valid
| 000 | [StreamsHub Proposal Template](./000-template.md) |
| 001 | [StreamsHub Quick-start Kustomize Repository](./001-quickstart-kustomize-repo.md) |
| 002 | [StreamsHub MCP: Strimzi MCP proposal](./002-streamshub-mcp-strimzi.md) |
| 003 | [Donation of streamshub-mcp to Strimzi](./003-donate-streamshub-mcp-to-strimzi.md) |