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 > > > > > > > > >
