Hello Vivek, I took a glance at your proposal. The proposal is promising at a high level, and the MCP/database-integration direction makes sense for AsterixDB. The strongest part is the idea of exposing query execution and schema discovery through a standard protocol instead of building one-off integrations. My main concern is scope. Right now this reads as MCP + A2A + persistent memory + session management + security hardening + performance work, which is likely too much for one GSoC project. I would strongly recommend narrowing the MVP to MCP first: tool discovery, query execution, schema introspection, authentication, limits, and tests. That alone would already be a meaningful contribution.
The memory section also needs simplification. Durable CRUD/retrieval for agent memory is a reasonable extension, but TTL/LRU eviction, session lifecycle management, and write-on-read access tracking add a lot of complexity for an initial version. A simpler durable storage model would make the implementation much more realistic. I would tighten the proposal by separating what already exists in AsterixDB from what this project will newly implement, especially around deployment, failover, and session state. Reviewers will want confidence that the design is grounded in the current server architecture rather than assuming infrastructure that is not already there. To answer your questions, 1. MCP first, Memory next, A2A if the first two are done successfully/completely. 2. For the MVP, the existing file-based credential approach is sufficient. It aligns with AsterixDB’s current HTTP authentication model and keeps the project focused on protocol integration rather than enterprise identity integration.The auth layer can be designed to be pluggable so Kerberos/OIDC/etc. can be added later. 3. Yes the MCP will be additive and a non-breaking change. If possible we will try to separate/make new components with little to no interference to existing modules. There aren't any open issues as of now related to what you have asked, but we always need help in improving our documentation. It is a good first task too. As I have mentioned in this thread, https://lists.apache.org/thread/4pjzd5q8910tototw7jrkrcq3vz4tcbp you can try to improve our docs for HTTP server APIs. Best, Suryaa On Mon, Mar 16, 2026 at 11:01 AM Vivek Gangavarapu < [email protected]> wrote: > I have a few clarifying questions about our architectural assumptions to > ensure my milestones align perfectly with the core team's vision: > > 1. Scope Priority: Should we prioritize MCP (agent-to-database) or A2A > (agent-to-agent coordination) first for the initial implementation? > 2. Security Model: The plan assumes BasicAuth wrapping for MCP/A2A > endpoints. Should we integrate with an existing identity provider (e.g., > Kerberos) or is the file-based credential approach sufficient for MVP? > 3. Backward Compatibility: The plan assumes MCP tools are additive only > (no breaking changes to existing query API). Is this the correct > approach? > > Regarding contribution opportunities: > To get started on this implementation, are there any open issues or tasks > related to: > > - HTTP server extensions or new servlet implementations? > - Metadata entity extensions (adding new entity types)? > - External function execution pipeline? > - Any pre-existing discussions on the [email protected] mailing > list about agent protocols? > > I'd prefer to start with a well-scoped first contribution before tackling > the full MCP/A2A implementation. Please point me toward any good first > issues or PRs that could help me understand the codebase patterns better. > Looking forward to collaborating on this! > > > On Sun, 15 Mar 2026 at 11:09, Suryaa Charan Shivakumar < > [email protected]> wrote: > > > Hello Vivek, > > > > Thank you for the detailed plan. Please use the same mail thread for > future > > discussions as well i.e reply to this same mail chain. > > I had just sent an email regarding the project in another thread, please > > check out - > > https://lists.apache.org/thread/scbgc598dhl3nwqlypv22qkgxxxpcjqn > > > > > > On Sat, Feb 21, 2026 at 6:07 AM Vivek Gangavarapu < > > [email protected]> wrote: > > > > > Hi Team, > > > > > > I spent the past two days setting up the local environment, compiling > the > > > master branch, and tracing through the core HTTP and Hyracks IPC layers > > to > > > understand how to best route Model Context Protocol (MCP) requests. > Based > > > on that deep dive, I've put together an initial architecture proposal > for > > > ASTERIXDB-3695 (LLM Agent Protocols/Memory). > > > > > > It covers the MCP and A2A integration with persistent agentic memory. > > > What's included: > > > > > > - > > > > > > Component breakdown and package structure > > > - > > > > > > Layer-to-layer flow diagrams (MCP request routing, A2A coordination, > > > memory flow, etc.) > > > - > > > > > > Data schemas for tools, agent cards, and memory datasets (leveraging > > > OPEN types) > > > - > > > > > > API endpoint definitions > > > - > > > > > > Implementation phases > > > - > > > > > > Key design decisions and extension points > > > > > > Link: > > > https://gist.github.com/Vivek1106-04/3ad2c921487f85ed198c6185ecf391cb > > > > > > This is my first draft — I'm happy to modify any part based on your > > > feedback. Things like SQL schema details, endpoint paths, or package > > naming > > > can be adjusted if they don't align with existing conventions. > > > > > > I've also requested a Jira account (pending approval) so I can comment > > > directly on the issue and track progress properly. > > > > > > Looking forward to your thoughts. > > > > > > Thanks, Vivek Gangavarapu > > > > > >
