Re: Polaris vs Polaris-Tools: I completely agree with all the points stated here: 1. Polaris-Tools could be considered a place to land items in the ecosystem that, if later widely used, could be folded into the main repo. 2. There are already clients (Spark Client & Python Client) inside the main repository, but other clients (the UI) are going to be put into Polaris-Tools.
To me, the repository matters less to me than coupling. I LOVE the current MCP Server design because it builds upon Polaris' primary public interface - the REST API. There are no "back channels" which bypass the primary public interface; there are no private APIs, etc. So, I would be fine going forward with Yufei's #2 proposal of putting it into a client/ folder as long as we have the understanding that we should not introduce coupling with anything that is not exposed as a REST API. Does that seem like an appropriate path forward? Cheers, Adam On Fri, Oct 31, 2025 at 7:55 PM Prashant Singh <[email protected]> wrote: > Thanks Yufei, It's a super useful utility IMHO and will be a good addition > to the project. > It's great to have it as an independent / standalone jar with all > dependencies contained. > > Regarding where it should live, I don't have a *strong opinion* on either > (polaris main repo vs polaris tools) as we > have python client as well as spark generic table integration client both > as part of main repo with the understanding being they can be moved to > polaris-tools if and when needed. > I perceive this as yet another client so my slight preference is keeping it > in the main repo, but totally open to moving it to the tools if the > consensus on that. > > Thank you proposal and all your work ! > > Best, > Prashant Singh > > On Fri, Oct 31, 2025 at 4:32 AM Jean-Baptiste Onofré <[email protected]> > wrote: > > > Hi > > > > I think the MCP server is a "client" for the Polaris server, like the > > CLI or the Console (UI). > > So, maybe it's worth considering polaris-tools as a host (it's what > > I'm doing to the Polaris Console). > > > > I'm more in favor of starting to land in polaris-tools repo and move > > later if it makes sense (I have the same feeling for the Polaris > > Console :)). > > > > Regards > > JB > > > > On Thu, Oct 30, 2025 at 7:33 PM Eric Maynard <[email protected]> > > wrote: > > > > > > This is a pretty cool project! > > > > > > I recall that originally the idea behind polaris-tools was that things > > > which are in the Polaris “ecosystem” could start there and potentially > be > > > folded into the core project if they wind up being really useful or > > widely > > > used. This hasn’t happened yet but I feel like we shouldn’t be afraid > to > > > put things in tools and move them later. > > > > > > I do view the MCP server as a kind of client to Polaris, and I agree > that > > > running it locally is probably the easiest thing for now. > > > > > > —EM > > > > > > On Thu, Oct 30, 2025 at 3:58 PM Yufei Gu <[email protected]> wrote: > > > > > > > Hi Adam, thanks for chiming in! > > > > > > > > I’m okay with either polaris (main) or polaris-tools. The POC > currently > > > > lives in the main repo, but it’s a standalone JAR, it neither depends > > on > > > > other modules nor has modules depending on it. Another option is to > > > > consider it as a client. We could put it along with the CLI client > > under > > > > "/client". These are all minor points. I will move it to the tool > repo > > if > > > > people feel strongly about it. > > > > > > > > It's a good idea to have an Iceberg MCP server. We might think of it > > as a > > > > separate effort. > > > > > > > > It's a POC, we will definitely add more context. And context > > engineering > > > > isn't just a one-time effort. It's a continuing project. I'm still > > > > trying to figure out a better way to do so, a better way means not > too > > much > > > > also not too less and more accurate. With that said, a remote MCP > > server is > > > > probably a better option, as the context update would be centralized. > > > > > > > > For availability and rolling upgrades, it’s fine that the MCP server > is > > > > local for now. We can address those concerns when we build out the > > remote > > > > MCP server. > > > > > > > > Yufei > > > > > > > > > > > > On Thu, Oct 30, 2025 at 7:44 AM Adam Christian < > > > > [email protected]> wrote: > > > > > > > > > This is fantastic, Yufei! I love this idea and the demo is > wonderful. > > > > > > > > > > A few thoughts: > > > > > > > > > > 1. I agree with your assessment that an MCP Server would > > complement > > > > > Polaris' other interfaces - REST, the python client, & the > future > > UI. > > > > > This > > > > > adds to the growing Polaris ecosystem and I know people will > find > > this > > > > > helpful. > > > > > 2. I agree with your approach of building an MCP Server rather > > than > > > > > using some sort of RAG approach (adding it to the chat context). > > It's > > > > a > > > > > seamless sort of integration that we see other vendors > leveraging > > as > > > > > well. > > > > > 3. I am unsure of whether this work should be integrated into > the > > > > > Polaris repository or the Polaris-Tools repository. I don't know > > how > > > > we > > > > > as > > > > > a community make the distinction. I know that the UI is going to > > be > > > > put > > > > > into the Polaris-Tools repository. Here's my understanding so > > far, but > > > > > I'd > > > > > love to chat about it: > > > > > 1. Polaris-Tools Pros: > > > > > 1. We don't want any hard dependencies between the core > > Polaris > > > > > codebase and the MCP Server. You have done a phenomenal > job > > > > > at doing this > > > > > by making the MCP Server be a shim between the REST API > and > > the > > > > AI > > > > > Application (Claude Desktop, 5ire, etc). > > > > > 2. This work might not be applicable for core use cases, > so > > it > > > > > would be an additional series of packages that would be > > > > > unused by users and > > > > > cause overhead for building and maintaining. > > > > > 2. Polaris Pros: > > > > > 1. It can leverage common infra (Gradle, etc). > > > > > 2. It'll be faster to develop. > > > > > 3. It'll be easier to keep in sync with the REST APIs > > (although > > > > > that applies to the UI as well). > > > > > 4. I'm wondering if we should create an Iceberg Catalog MCP > > Server > > > > > and a Polaris MCP Server. A lot of the tools that you created > > would > > > > > benefit > > > > > the wider Iceberg Catalog ecosystem and are not > Polaris-specific. > > For > > > > > example, the polaris-namespace-request and the > > polaris-table-request > > > > are > > > > > just Iceberg Catalog operations. What are your thoughts there? > > > > > 5. For some of the issues that you have observed with setting > > > > > privileges, I believe that we might be able to improve the > > accuracy by > > > > > updating the tools' descriptions. You & I can chat about this > > offline, > > > > > but > > > > > from my analysis of the code, we can make those descriptions > much > > > > richer > > > > > and that'll increase accuracy without too much additional work. > > I've > > > > > seen > > > > > this in other MCP Servers that I've built. But, we can handle > this > > > > after > > > > > we've released the first version. It's a small change. > > > > > 6. I know this is early days, but have you thought about what > > sort of > > > > > availability you would want with the MCP Server? Like, Polaris > > tries > > > > to > > > > > support rolling upgrades [1]. Is that your intention here? > > > > > > > > > > Thanks for doing all this work. I'm excited about where this is > > going! > > > > > > > > > > [1] - https://polaris.apache.org/in-dev/unreleased/evolution/ > > > > > > > > > > Cheers, > > > > > > > > > > Adam > > > > > > > > > > On Tue, Oct 28, 2025 at 4:30 PM Yufei Gu <[email protected]> > > wrote: > > > > > > > > > > > Hi all, > > > > > > > > > > > > I’d like to propose the Polaris MCP Server, which lets users and > AI > > > > > agents > > > > > > interact with Polaris using natural language instead of REST or > > CLI. > > > > > > Example: “Show me all tables in prod.sales updated in the last 7 > > days.” > > > > > > > > > > > > It runs locally, connects to Polaris via REST, and requires no > > backend > > > > > > change. Privileges are limited to the authenticated Polaris user. > > > > > Supports > > > > > > OAuth2 client credentials and direct bearer tokens. > > > > > > > > > > > > This bridges Polaris with LLM-based tools like Claude and Cursor, > > > > laying > > > > > > the groundwork for agentic catalog operations. > > > > > > > > > > > > Design Doc: > > > > > > > > > > > > > > > > > > > > > > > > https://docs.google.com/document/d/1yA_d3netDzgicn0z5HEGZIIOHcCgTJC1eKx_DTZPXps/edit?usp=sharing > > > > > > A Java-based, working POC: > > https://github.com/apache/polaris/pull/2803 > > > > . > > > > > I > > > > > > demoed it at this event https://luma.com/pxikwty3. > > > > > > Yufei > > > > > > > > > > > > > > > > > >
