Hi Suryaa, I have completely restructured the proposal based on your incredibly helpful feedback. I have updated the draft, which you can review here: New-draft <https://drive.google.com/file/d/1bJf1buAXWTrTxZPTK4as08Mr0f6kyA6z/view?usp=drive_link> .
Here are the key changes I made to ensure the scope is realistic for the 12-week timeline: 1. *MVP Focus:* The timeline is now strictly focused on the MCP protocol (tool discovery, query execution, schema introspection, rate limits). 2. *Memory Simplification:* The memory section is now limited to basic durable CRUD operations leveraging existing LSM storage. 3. *Scope Reduction:* A2A and complex memory features (TTL/LRU) have been explicitly moved to Stretch Goals / Future Work. 4. *Architecture Clarity:* I added a clear matrix and updated the diagrams to explicitly define what existing AsterixDB infrastructure I am leveraging versus what new code I am writing. Regarding my first contribution, thank you for pointing me toward the documentation! I will trace the existing API paths, update the documentation to reflect the current state, and raise a Pull Request in the next few days. I will ping you once the PR is up for review. Thanks again for steering the proposal in the right direction and helping me find a solid first issue! Best regards, Vivek On Fri, 20 Mar 2026 at 12:16, Suryaa Charan Shivakumar < [email protected]> wrote: > 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 > > > > > > > > > >
