I see, that's really cool it just uses uvx like that. And, that the MCP server just needs the server info, basically. Very tidy.
I think that it should be a separate repo within the Apache namespace. This is what we did for the JDBC driver (asterix-clients). Maybe it can go there, or be it's own repo (asterix-mcp)? @Suryaa any thoughts/suggestions? On Wed, Jul 15, 2026 at 7:15 PM Vivek Gangavarapu <[email protected]> wrote: > > 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 > >
