Move someparth into future proposals

Signed-off-by: David Kornel <kornys@outlook.com>

Author: kornys

001-streamshub-mcp-strimzi.md

@@ -421,15 +421,10 @@ This way a user can only see Strimzi resources in namespaces their MCP server in
   See [Log Handling](#log-handling) for details.
 
 **MCP server authentication and authorization**:
-The MCP protocol (since the [2025-06-18 spec](https://modelcontextprotocol.io/specification/2025-11-25)) supports OAuth 2.1 for both authentication and authorization.
-We can control who can connect to the MCP server and what tools they can call using OAuth scopes.
-If a client tries to call a tool it doesn't have the right scope for, the server responds with 403 and tells the client what scopes it needs (step-up authorization).
-
-Quarkus provides OIDC support for this ([example](https://quarkus.io/blog/secure-mcp-oidc-client/)).
-
-Authorization works at two levels:
-- **MCP level**: OAuth scopes control which tools a user can call (e.g., a read-only scope for logs vs. a scope that also allows metrics access).
-- **Kubernetes level**: The MCP server's Service Account and namespace-scoped RoleBindings control which Strimzi resources it can see (described in the authorization model above).
+The MCP protocol supports OAuth 2.1 for authentication and authorization ([spec](https://modelcontextprotocol.io/specification/2025-11-25), [Quarkus OIDC example](https://quarkus.io/blog/secure-mcp-oidc-client/)).
+This is out of scope for the initial implementation.
+For now, we rely on Kubernetes RBAC (the Service Account and RoleBindings described above) to control access.
+MCP level auth/authz can be proposed separately later as it will be reused by other MCP servers in StreamsHub-MCP
 
 #### Prompt Injection Protection
 
@@ -457,29 +452,18 @@ Log retrieval needs some care to avoid returning too much data or leaking sensit
 
 #### Metrics Strategy
 
-The MCP server supports two approaches for accessing metrics, configured at deployment time:
-
-**Direct pod scraping**:
-Read raw metrics from Strimzi pod Prometheus endpoints (e.g., the Kafka broker's JMX exporter endpoint).
-- Useful when no Prometheus instance is deployed.
-- Simpler setup, only needs pod access via the MCP server's Service Account.
-- Adds scraping load on the pods (on top of any existing Prometheus scraping).
-- Limited to point-in-time metrics, no historical data.
+The initial implementation will read metrics directly from Kafka broker pods, either from the [Strimzi Metrics Reporter](https://github.com/strimzi/metrics-reporter) or from the Kafka JMX exporter endpoint, depending on what the user has configured.
+This only needs pod access via the MCP server's Service Account.
 
-**Prometheus integration**:
-Query an existing Prometheus API for Strimzi related metrics.
-Requires a Prometheus instance to be deployed and scraping Strimzi pods.
-- Uses existing monitoring infrastructure.
-- Gives historical data and pre-aggregated metrics.
-- Needs the Prometheus API endpoint and any auth credentials to be configured.
-- Avoids duplicating scraping load.
+Prometheus API integration (querying an existing Prometheus instance for historical and aggregated metrics) is out of scope for this proposal and can be added in a separate proposal later.
 
 **Caveats**:
-- Custom metric names: Strimzi and Kafka metric names can be customized by users, so the MCP server supports configurable metric name mappings.
+- Custom metric names: Strimzi and Kafka metric names can be customized by users, so the MCP server will need configurable metric name mappings.
 - RBAC: Direct pod scraping needs `get` on `pods/metrics` or port-forwarding access.
-  Prometheus integration needs access to the Prometheus API, which may have its own auth setup.
+- Direct pod scraping only gives point-in-time metrics, no historical data.
+  For historical data, Prometheus integration would be needed.
 
-**What metrics answer**: Metrics are mostly useful during ad-hoc incident investigation, for example "Is the broker under heavy load?", "What's the replication lag?", "Are there under-replicated partitions?".
+Metrics are mostly useful during ad-hoc incident investigation, for example "Is the broker under heavy load?", "What's the replication lag?", "Are there under-replicated partitions?".
 For ongoing monitoring, existing alerting infrastructure (Prometheus alerts, Grafana) is still the primary tool.
 
 ### Deployment & Delivery