Great initiative Tanishq, thanks for driving this! It's not always easy to get the perfect design right from the beginning before having actual feedback from the users. The two questions are important but we shouldn't overthink them.
As every new API/component it may not be production ready from day one. A reasonable path forward is to pick one direction, mark the component/API experimental, document all potential caveats/gaps, and then once the first use cases are established we can refine our decision if necessary. This is to say that I feel comfortable letting Tanishq lead the initiative and make the final decision. If others feel strongly about one direction or the other then please let Tanishq know as soon as possible to avoid any potential -1 comments during the code review. Regarding code placement, we can be flexible as well but it may be a bit premature to make a decision now since we don't have any idea on how the actual implementation looks like. I don't even know if we are talking about maven + Java code or something completely different. By default, everything goes to the main Apache Hive repo except stuff that is bad for version control, or not meant to be part of the release cycle. Best, Stamatis On Fri, Aug 28, 2026 at 8:45 AM Tanishq Chugh <[email protected]> wrote: > Hi, > > Thank you all for the great feedback and valuable insights on this > proposal. > > I see that we are inclined to store the MCP code in the Apache/Hive > Repository itself, and I stand by it too, as it ensures the MCP remains in > sync with new Hive changes and advancements, and it also aligns with > release packaging. > > However, we have mixed valuable insights regarding whether to proceed with > a single unified MCP or separate HS2 / HMS MCPs. I acknowledge the fact > that HMS is used standalone with other engines and having an MCP server > just for HMS can indeed serve a larger audience. To support this use > case, I initially envisioned the unified MCP as a config-controlled > plug-as-per-use design, allowing it to run only to serve Metadata (from the > Iceberg REST Catalog and/or HMS Thrift APIs) if needed. > > In my opinion, having separate MCPs adds to the fixed infrastructure costs > and deployment/maintenance overhead at the user end. However, I also > acknowledge that Separate MCPs can be more Fault Tolerant. > > Considering all these pointers in the thread, we still need to lock in > which approach to take. I am not completely biased towards a unified MCP, > and given the strong valuable points raised in favor of decoupling, I would > appreciate further discussion to help us settle on the best design, as our > aim is to develop and deliver a product that provides the most value and > usability to the end-user :) > > Thanks! > > Best, > Tanishq Chugh >
