Hi Tanishq, Thanks for driving the initiative. I'm happy to see HIVE-29370 and HIVE-29681, which add new values to Hive Metastore. I think Hive should become an Open Agentic Cloud-Native Lakehouse Platform; this initiative will fill the last piece :)
> 1. Should we have separate MCP servers for Metadata (HMS) & Query Execution > (HS2), or one MCP server that can serve both? I am biased toward a unified MCP, letting Hive operators and users choose which features are enabled via configuration and OAuth 2 scopes, for two reasons. First, as Tanishq says, SELECT queries can be useful even for finding metadata. Second, although Lakehouse started as query-engine agnostic, recent important topics such as table maintenance, Server-Side planning, materialized views, etc. are coupled with some compute engines by design. I guess we might be able to provide an integrated experience if the MCP server can access both HS2 and HMS. I'm not so confident, though. > 2. Where do we plan to store the MCP code? Should we store it in our > Apache/Hive repository itself or in a separate repository? I'd say starting in apache/hive is easy, though I don't have a strong opinion. Best, Okumin On Tue, Aug 25, 2026 at 5:20 PM Denys Kuzmenko <[email protected]> wrote: > > Hi Tanishq, > > +1 for the initiative and the overall direction. > > One point I would consider is keeping the HMS MCP separate from the Hive > query execution MCP. HMS is already a standalone component that can be > deployed and released independently of Hive, and it is used by engines beyond > Hive itself, such as Spark, Trino, and Impala. > > Because of that, an HMS-focused MCP could provide metadata discovery > capabilities as a reusable integration point for the broader ecosystem, > without coupling those capabilities to HiveServer2 or query execution. > > The two MCP servers could still share common code or APIs where appropriate, > but having independently deployable MCP endpoints seems more aligned with the > existing HMS architecture and its role as a shared metadata service. > > Best, > Denys
