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