Hell Ian, I also lean towards a dedicated asterix-mcp repository. It feels like a natural fit since the MCP server has its own lifecycle, packaging (PyPI/uvx), and client-facing concerns, while remaining loosely coupled to AsterixDB through the existing REST APIs. Following the asterix-clients precedent seems like a clean direction.
Best, Suryaa On Thu, Jul 16, 2026 at 3:56 PM Ian Maxon <[email protected]> wrote: > 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 > > > >
