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
>
