Hi Vivek, I agree it makes sense to keep the MCP server separate from the CC. It's more tightly tied with the lifecycle of the agent using it than it is the cluster. I don't know that it should start with the server either. Generally, I would imagine the MCP server running wherever the agent is, rather than where the cluster is. I think having it follow whatever packaging idioms these follow would make the most sense. Have you found a typical way this happens? Or is it all kind of chaotic still? For example, say I wanted to use Claude Code with this MCP server, against a real AsterixDB cluster, not just a local instance. How would I get and configure the MCP server for that?
- Ian On Wed, Jul 8, 2026 at 9:10 AM Vivek Gangavarapu <[email protected]> wrote: > > 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
