Three tools is the whole surface, and that is the point — the JDBC driver turns BigCommerce 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 BigCommerce behind three SQL tools. CData's JDBC Driver for BigCommerce 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.
- `bigcommerce_get_tables` returns the tables the driver exposes, as CSV with a header row
- `bigcommerce_get_columns` returns the columns on one table, in the same CSV shape
- `bigcommerce_run_query` executes a SQL SELECT statement
- The `bigcommerce` part is the `Prefix` you set in the property file (`Prefix=bigcommerce` 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 BigCommerce separately and license it — `java -jar cdata.jdbc.bigcommerce.jar --license`, then name, email, and TRIAL or your key. Write a `bigcommerce.prp` file carrying `DriverClass=cdata.jdbc.bigcommerce.BigCommerceDriver` and the JDBC URL from the driver's connection-string utility, and launch the server as `java -jar CDataMCP-jar-with-dependencies.jar bigcommerce.prp`. Transport is stdio, so the server runs on the same machine as the client.