Hi all, Ship the MCP server as a standalone sidecar process, not embedded in the Cluster Controller.
Concretely: - It's a separate module in the tree and packaged into the asterix-server binary assembly. - It launches from the same start script that brings up NC/CC (start-sample-cluster.sh), gated behind an enable flag. - Flag off (the default) => the cluster is byte-identical to today: no extra process, no new port, nothing launched. - The sidecar talks to the CC only through the existing stateless /query/service REST endpoint. So: one command brings up the wired stack when you want it, and teardown mirrors it — but a normal deployment that doesn't care about MCP is completely unaffected. Why keep it out of the CC? The honest reason is that MCP is a stateful, streaming protocol and the CC is deliberately not. An MCP session holds long-lived SSE streams and per-session state (session IDs, output streams). If we host that inside the CC we'd be pushing exactly the kind of long-held connections and session state that the control plane is designed to avoid — and it works directly against the CC's stateless failover behavior. What I'm asking 1. Does "sidecar in the assembly, launched by the start script behind a flag" sit right with how the community wants optional components to ship? Or would you rather it stay a fully external, separately-installed thing? 2. Any objection to the flag-off-is-a-no-op contract as the safety default? 3. Anything about the module layout or the assembly packaging I should line up with existing conventions before I put up a patch. Thanks, Vivek
