Hello Vivek, Thank you for the demo today. It was great to see some new features in the UI after a long time. Here are some comments, 1. As Mike pointed out, the design should be consistent with the rest of the UI, please reuse existing components, font and colors. 2. When the Chat window is empty, add some guide/info on hotkeys like / and @ and what they do with examples. Try to keep the Connect flow linear and not switch tabs, ease of UX is important. 3. You mentioned conversation history is stored somewhere, do we make use of the DB for this or file system (this should be robust, depending on where asterixdb UI is deployed. It is mostly the same server as the core DB?). This might also be a future step towards agentic memory/harness.
Best, Suryaa On Wed, Jun 24, 2026 at 7:22 AM Suryaa Charan Shivakumar < [email protected]> wrote: > Hello Vivek, > > Yes please use Ian’s patch as we see that as the way forward. Feel free to > share feedback if you see anything behaving unexpectedly or if you can > improve it. > > Best, > Suryaa > > On Wed, Jun 24, 2026 at 2:00 AM Vivek Gangavarapu < > [email protected]> wrote: > >> On the UI side, the dashboard is ancient ( Angular 10). I saw Ian's patch >> on gerrit (21081, ASTERIXDB-3763) migrates the whole thing to Angular 21 >> and Bun. Reading the patch, the dashboard already uses NgRx and has >> plan-viewer, tree-view and metadata-inspector components. Therefore, MCP >> calls will become NgRx effects like everything else, and we can reuse the >> existing renderers instead of rebuilding them. Should I check out the >> Angular 21 patch branch locally and build the MCP UI on top of it? >> >> Thanks, >> vivek >> >> On Wed, 24 Jun 2026 at 09:06, Mike Carey <[email protected]> wrote: >> >> > 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 >> > > >> > >> >
