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 >
