Describe the subtask
Follow-up to #11574 / #11693. The MCP server already exposes
list_statistics_for_partition, but there is no tool to discover partition
names/infos, so an agent has no way to obtain the from/to partition inputs
that tool requires. Add read-only partition tools following the established
pattern (interface → plain REST client impl → FastMCP tool → mock → unit tests),
with authorization enforced by Gravitino.
Proposed tools:
list_of_partitions(catalog, schema, table, details=false) — GET .../tables/{table}/partitions (names, or full infos when details=true).
get_partition(catalog, schema, table, partition) — GET .../tables/{table}/partitions/{partition}.
Scope: read-only (list/get). Partition add/drop (write) can be a later subtask.
The backend REST already exists (PartitionOperations, both GETs gated by
LOAD_TABLE_AUTHORIZATION_EXPRESSION), so authorization-scoped discovery is
inherited automatically — no filtering logic added in the MCP layer.
Parent issue
#11573
Describe the subtask
Follow-up to #11574 / #11693. The MCP server already exposes
list_statistics_for_partition, but there is no tool to discover partitionnames/infos, so an agent has no way to obtain the
from/topartition inputsthat tool requires. Add read-only partition tools following the established
pattern (interface → plain REST client impl → FastMCP tool → mock → unit tests),
with authorization enforced by Gravitino.
Proposed tools:
list_of_partitions(catalog, schema, table, details=false)—GET .../tables/{table}/partitions(names, or full infos whendetails=true).get_partition(catalog, schema, table, partition)—GET .../tables/{table}/partitions/{partition}.Scope: read-only (list/get). Partition add/drop (write) can be a later subtask.
The backend REST already exists (
PartitionOperations, both GETs gated byLOAD_TABLE_AUTHORIZATION_EXPRESSION), so authorization-scoped discovery isinherited automatically — no filtering logic added in the MCP layer.
Parent issue
#11573