Three tools is the whole surface, and that is the point — the JDBC driver turns API Driver into ordinary tables, so the model writes SELECT statements instead of learning an API shape. What you trade for that is a driver install and a licensing step before the first query, and a server that only reads: there is no write, update, or delete path here.
A local Java server that puts API Driver behind three SQL tools. CData's JDBC Driver for API Driver exposes the service as relational tables, and this server wraps the driver so a model can find a table, read its columns, and run a SELECT against live data without anyone writing the API calls.
- `apidriver_get_tables` returns the tables the driver exposes, as CSV with a header row
- `apidriver_get_columns` returns the columns on one table, in the same CSV shape
- `apidriver_run_query` executes a SQL SELECT statement
- The `apidriver` part is the `Prefix` you set in the property file (`Prefix=apidriver` in the sample), so several CData servers can sit in one client without their tool names colliding
- Leave `Tables=` empty to reach everything, or list table names there to expose only those
Build it yourself: clone the repository and run `mvn clean install`, which produces `CDataMCP-jar-with-dependencies.jar`. Install the CData JDBC Driver for API Driver separately and license it — `java -jar cdata.jdbc.apidriver.jar --license`, then name, email, and TRIAL or your key. Write a `api-driver.prp` file carrying `DriverClass=cdata.jdbc.apidriver.APIDriverDriver` and the JDBC URL from the driver's connection-string utility, and launch the server as `java -jar CDataMCP-jar-with-dependencies.jar api-driver.prp`. Transport is stdio, so the server runs on the same machine as the client.
Build from source — clone the repository and build it, then point your client at the binary