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
