Hi Vivek, Thanks for sharing this, and condensing everything into an APE. It looks really neat overall, and well designed to be relatively self-contained. I think one of the concerns that I had, at least, is that a lot of things in the area of LLMs move very quickly. Since AsterixDB is a relatively mature and stable codebase at this point, keeping it modular to the extent possible lets this move at its own pace, rather than being held up by practices and standards intended to constrain change for longstanding things within AsterixDB.
I have some very high level questions about the MCP side of the repo. You will have to forgive me for my ignorance; I only really know about what has been going on in this area from a few brief words here and there either from you or Suryaa off-list. Maybe even one of you have answered some of these in the past and I have simply forgotten. 1 ) What language is it written in? 2 ) Does it need CI for each new change, or would that kind of be overkill? 3 ) It's mentioned it is a sidecar of sorts. How does this usually work? 4 ) Is there a possibility to get a walkthrough on how to compile and run everything, end-to-end? I know the goal I have talked about with Suryaa and you is that it should all go in the asterixdb-mcp repo, but until we close that loop, just whatever exists in a GitHub repo or fork would be fine. Thanks for all your hard work on this so far. All the demos I have seen of it look super neat. The fact things are taking a long time isn't a reflection on the quality of your effort, it's just that some things around here tend to get the lion's share of attention, and other things that are very interesting but not perceived as urgent can get less attention than they deserve. - Ian On Fri, Aug 28, 2026 at 10:27 AM Vivek Gangavarapu <[email protected]> wrote: > > Hi all, > > Initiating discussion on APE 36, an MCP gateway for AsterixDB. > > Feature: MCP Gateway > > The gateway lets agent clients talk to a cluster over MCP instead of being > handed /query/service and a prompt. It exposes the catalog, dataset > schemas, optimizer and Hyracks plans, ADVISE index recommendations and > cluster diagnostics as MCP tools, with results bounded so a SELECT * > doesn't fill the model's context. It runs as a standalone sidecar, not > inside the CC: MCP to the client, plain HTTP to the CC, no cluster state > and no caching. It also never decides for itself whether a statement > mutates — it sets readonly=true and lets the engine reject, rather than > keeping a deny-list that would drift from the grammar. > > Inside AsterixDB the change is small: function_metadata() (21483) so the > gateway reads the live function registry, and an optional /mcp proxy plus > dashboard panel (21492), off by default. > > APE: > https://cwiki.apache.org/confluence/spaces/ASTERIXDB/pages/449286300/APE+36+AsterixDB+MCP > > Thanks, > Vivek
