vinishjail97 opened a new issue, #891: URL: https://github.com/apache/incubator-xtable/issues/891
### Feature Request / Improvement Expose XTable's operations as MCP tools, over a single shared tool registry, so any MCP client can drive a conversion without XTable shipping product-specific integrations. ## Design Follow the pattern `apache/hudi` used in `hudi-agent-gateway`: define each tool once in a registry, and let every surface expose it. In their words, one registration reaches the agent loop, the MCP server, the tool-listing endpoint and the invocation log. For XTable that means the MCP surface sits on the same tool layer as the REST service (#666), not beside it. Two APIs with drifting behaviour is the outcome to avoid. ## Proposed v1 tools - `validate_config` — check a `datasetConfig` against the generated schema and return actionable errors. - `inspect` — given a path, report the detected format, schema, partitioning and commit or snapshot count. PR #830 makes the detection part nearly free. - `convert` — run a sync and return the structured result. - `diagnose` — classify a failure into a named cause (missing format jar, partition-spec mismatch, unsupported type, permission) and give the remedy. - `verify` — compare source and target after a conversion and summarise equivalence. ## Guardrails Hudi's v1 tools are read-only queries. XTable's central operation writes metadata, so this needs more care than their case did: - `convert` defaults to dry-run and requires an explicit flag to write. - Every invocation logged as structured JSON. - Result truncation and time limits, so a large table cannot flood a model's context. - No credentials in tool arguments. ## Open questions - Language. Hudi chose Python for the agent layer despite being a JVM project, because that ecosystem is Python-first. XTable's tools wrap XTable's own Java code and need no third-party agent framework, so Java with the MCP Java SDK is also defensible. Worth deciding deliberately. - Whether this is a module in this repo or a separate deployable, which depends on how #666 is packaged. ## Depends on The agent-legible CLI and the generated config schema, both linked from the parent issue. `convert` and `validate_config` are thin wrappers once those exist. ### Are you willing to submit PR? - [x] Yes I am willing to submit a PR! ### Code of Conduct - [x] I agree to follow this project's [Code of Conduct](https://www.apache.org/foundation/policies/conduct) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
