This sounds like fabulous progress! On Tue, Jun 23, 2026 at 8:03 PM Vivek Gangavarapu < [email protected]> wrote:
> Hi all, > > Quick update on the MCP gateway + a few things coming up that I'd like your > thoughts on. > > What works so far > > Browsing dataverses, datasets, and datatypes, and running SQL++ (it deals > with the async job stuff for you). > Index help — it can list indexes and suggest new ones, using AsterixDB's > own ADVISE first and a simple heuristic when there are no stats to go on. > Seeing what the cluster's doing — list running queries, cancel one, and an > EXPLAIN-ANALYZE-style tool that gives real per-operator numbers (rows, I/O, > time). > Plus a tool that reads ANALYZE SAMPLE stats to estimate dataset size and > cardinality. > Every tool checks its input before it hits the cluster and hands back a > clear "here's what was wrong" message, so a bad call fixes itself instead > of just failing. > > I've kept the tool count small on purpose(below 30). The code is here: > AsterixDB > MCP server <https://github.com/Vivek1106-04/asterixdb-mcp-server.git> > > What's coming up > > 1. Geospatial. AsterixDB just landed a pile of spatial work. I want the > gateway to expose all of it, but it's a big area and still moving, so it'll > take a bit more work to get right. My current plan: rather than keep a > hand-written list of geo functions (which goes stale the second someone > adds another), just lean on the list-functions tool that's already there — > it pulls the engine's functions with a category, so the spatial ones come > along automatically and stay current. > > 2. A dataset storage tool. Something that shows, per dataset, how big it > really is on disk — LSM partition bytes and partition count. Good for > catching skew, understanding storage cost, and making smarter index > decisions. I'm fairly sure those numbers are reachable from where the > gateway sits, but if anyone closer to the storage layer knows a catch, I'd > like to hear it. > > 3. A UI. Right now everything goes through the MCP protocol, which is great > for assistants but not much to look at for a human. I'm going to start > building an Angular front end for it — running locally at > http://localhost:19006 to begin with — so you can actually see the tools, > poke at queries, and watch what the assistant is doing in a browser instead > of reading raw protocol traffic. Early days on this, so if you've got > opinions on what a UI like this should show first, or features that'd make > it genuinely useful. > > Thanks, > Vivek >
