[DISCUSS] MCP server — deploy as a sidecar, not inside the CC

[Vivek Gangavarapu <ga...@gmail.com>]

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

Re: [DISCUSS] MCP server — deploy as a sidecar, not inside the CC

[Mike Carey <dt...@gmail.com>]

Hell yes!  :-)

(I agree.)

On 7/24/26 10:15 AM, Suryaa Charan Shivakumar wrote:
> 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<im...@apache.org> 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
>> <ga...@gmail.com> 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<im...@apache.org> 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
>>>> <ga...@gmail.com> 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

Re: [DISCUSS] MCP server — deploy as a sidecar, not inside the CC

[Suryaa Charan Shivakumar <su...@ucr.edu>]

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 <im...@apache.org> 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
> <ga...@gmail.com> 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 <im...@apache.org> 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
> > > <ga...@gmail.com> 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
> > >
>

Re: [DISCUSS] MCP server — deploy as a sidecar, not inside the CC

[Ian Maxon <im...@apache.org>]

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
<ga...@gmail.com> 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 <im...@apache.org> 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
> > <ga...@gmail.com> 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
> >

Re: [DISCUSS] MCP server — deploy as a sidecar, not inside the CC

[Vivek Gangavarapu <ga...@gmail.com>]

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 <im...@apache.org> 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
> <ga...@gmail.com> 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
>

Re: [DISCUSS] MCP server — deploy as a sidecar, not inside the CC

[Ian Maxon <im...@apache.org>]

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
<ga...@gmail.com> 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