Hi Ian, Good news is it's not chaotic anymore — this settled over the last year or so. For Python servers the norm is a PyPI package that clients run with uvx (uv's tool runner — it pulls the package, resolves deps into a throwaway venv, and runs it, all in one command). Node servers do the same dance with npm and npx — MongoDB's MCP server ships that way. And there's now an official MCP Registry (registry.modelcontextprotocol.io) that sits on top: it doesn't host code, just verified metadata pointing at the PyPI/npm package, so clients can discover servers. Docker images show up too, mostly for hosted deployments.
So for your Claude Code example, once we publish to PyPI it's literally one command: claude mcp add asterixdb --env ASTERIXDB_MCP_CC_BASE_URL=http://<cc-host>:19002 -- uvx asterixdb-mcp-server That runs the MCP server on the machine where Claude Code runs (which matches your instinct — it lives with the agent, not the cluster) and it talks to the remote cluster over the regular query API on 19002. Everything is env-var configured, so pointing at a different cluster is just that one URL. For the case where a team wants one shared server near the cluster instead, the HTTP transport already exists (with bearer/OAuth auth), and then clients just add the URL. Same package either way. The only real decision left is what namespace we publish under — PyPI name and registry namespace — which is probably an Team-level call. Vivek On Thu, 16 Jul 2026 at 02:55, Ian Maxon <[email protected]> wrote: > 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 >
