This build is explicitly the read-only one — the vendor points elsewhere for write, update and delete or for a fully remote managed setup. Combined with stdio-only transport, that means the data never leaves the machine running the client, and no tool here can modify a table. The setup is longer than most: a Maven build, a licensed driver install and a hand-written connection file before anything runs.
A local, read-only server that wraps the CData JDBC Driver for Databricks. The driver exposes Databricks as relational SQL models; this server puts three tools in front of that, so a model can discover the schema and then query it without anyone writing SQL by hand.
- The tables available in the data source, returned as CSV with a header row — `databricks_get_tables`
- The columns on a named table, in the same CSV shape — `databricks_get_columns`
- A SQL SELECT executed against the source — `databricks_run_query`
- Control over what is reachable: the `Tables` property in your connection file is left blank for everything, or lists explicitly the tables you want exposed
- A configurable tool prefix, so several CData servers can run side by side without name collisions
Java and Maven: clone the repository and run `mvn clean install`, which produces `CDataMCP-jar-with-dependencies.jar`. Separately install and license the CData JDBC Driver for Databricks — run `java -jar cdata.jdbc.databricks.jar --license` and enter TRIAL or your key. Build the connection string with the driver's utility, then write a `.prp` file carrying `Prefix`, `ServerName`, `ServerVersion`, `DriverPath`, `DriverClass` and `JdbcUrl`. Your client launches java with the jar and the `.prp` path. It speaks stdio only, so the client must run on the same machine as the server.