Actually I was saying the opposite - the rest of the UI should use
Vivek's style choices! They look nicer IMO.
On 6/26/26 10:41 AM, Suryaa Charan Shivakumar wrote:
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
