Updated. I will post the PR soon. Thanks and Regards Xu
Xavier Bai <[email protected]> 于2026年7月17日周五 15:05写道： > Thanks, Jinsong. These suggestions are very helpful. I’d like to provide > some additional context about the AIP. > > Jinsong Zhou <[email protected]> 于2026年7月17日周五 14:40写道： > >> Hi, >> >> Thanks for the well-structured proposal. The motivation is clear — >> wrapping >> AMS REST APIs behind semantic, read-only MCP tools significantly lowers >> the >> integration barrier for AI agents while maintaining a strong security >> posture. The scope is appropriately restrained, and the authentication >> model (particularly the request-scoped amoro mode preventing >> credential >> fallback) is well designed. +1 from me. >> >> Two suggestions for consideration: >> 1. AMS version compatibility and runtime version check >> The proposal states it targets the 0.9 development branch, but does not >> specify a minimum supported AMS version or a backward-compatibility >> policy. >> Since the MCP server communicates with AMS purely through REST APIs, it >> would be valuable to: >> ⦁Declare the minimum compatible AMS version explicitly. >> ⦁Implement a runtime version check (e.g., during the readiness probe or >> on >> first request) that warns or fails fast when connecting to an unsupported >> AMS version. >> ⦁Clarify whether the MCP server intends to maintain backward >> compatibility >> with older AMS releases in future versions, or whether it will track the >> latest AMS release only. >> This is especially important because the MCP server is deployed >> independently from AMS, and version skew between the two is expected in >> practice. >> >> 2. Future diagnostic tools >> The initial toolset covers the core navigation and inspection flow well. A >> few additional diagnostic tools would be valuable as follow-up additions >> (not necessarily in the first release): >> ⦁Cross-catalog table search: a search_tables tool that accepts >> keywords and searches across catalogs and databases, enabling agents to >> locate tables without knowing the full catalog→database→table hierarchy in >> advance. >> ⦁Table health summary: a tool exposing stale snapshots, partition >> distribution anomalies, or optimization lag — common operational >> diagnostics that align naturally with the read-only, diagnostic-oriented >> scope. >> These can be introduced incrementally as the MCP surface matures and usage >> patterns from real agents become clearer. >> >> Overall, great proposal — looking forward to seeing this move forward. >> >> Best, >> Jinsong >> >> On Fri, Jul 17, 2026 at 10:59 AM Xavier Bai <[email protected]> wrote: >> >> > Hi devs, >> > >> > I would like to start a discussion about AIP-6: Introduce an MCP Server >> for >> > Apache Amoro [1]. >> > >> > Today, MCP clients and AI agents that inspect Amoro must understand the >> AMS >> > REST route hierarchy, authentication and request-signing rules, >> pagination >> > conventions, and response structures. AIP-6 proposes an official >> > standalone, read-only MCP Server backed by the existing AMS REST GET >> APIs. >> > >> > The initial scope contains 11 tools: >> > >> > - list_catalogs >> > - list_databases >> > - list_tables >> > - get_table_details >> > - list_table_snapshots >> > - list_optimizing_processes >> > - list_optimizing_tasks >> > - list_optimizers >> > - list_optimizing_tables >> > - list_resource_groups >> > - check_ams_connectivity >> > >> > Snapshot access is bounded, paginated, projected, and redacted. >> File-level >> > queries, operation history, generic REST proxying, and all write actions >> > are out of scope. >> > >> > The main security boundaries are: >> > >> > - an explicit GET-only action allowlist; >> > - strict input validation and bounded responses; >> > - projection and redaction of sensitive fields; >> > - no arbitrary URLs, HTTP methods, or raw AMS response passthrough. >> > >> > The proposal uses an independently deployable Python/FastMCP service >> and is >> > based on the AMS REST interfaces available on the current master branch. >> > >> > I would especially appreciate community feedback on: >> > >> > - whether the server should live in the Amoro monorepo; >> > - the initial public tool contract; >> > - the authentication model; >> > - release expectations. >> > >> > The full proposal is available on the wiki [1], and the tracking issue >> is >> > [2]. >> > >> > [1] >> > >> > >> https://cwiki.apache.org/confluence/spaces/AMORO/pages/440304643/AIP-6+Introduce+an+MCP+Server+for+Apache+Amoro >> > [2] https://github.com/apache/amoro/issues/4266 >> > >> > Best regards, >> > Xavier Bai >> > >> >
