Expose an MCP surface over a shared XTable tool registry

[vinishjail97]

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 Detect Source Table Format #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 XTable REST Service for metadata and catalog sync. #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?

• Yes I am willing to submit a PR!

Code of Conduct

• I agree to follow this project's Code of Conduct