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