The whole design is one driver away from being a generic SQL server: CData maps Twitter Ads onto relational models and the assistant gets table discovery plus a read query. That makes the blast radius easy to reason about — there is no write path to get wrong — and caps what you can ask at whatever the driver's schema exposes. The cost is front-loaded: a Maven build, a licensed driver install and a hand-written property file before the first question.
A local, read-only bridge between an assistant and Twitter Ads. CData's JDBC driver exposes Twitter Ads as relational SQL models; this server wraps the driver so a model can discover the tables and query them, and you can ask in plain language instead of writing SQL. It runs over stdio, so the client has to be on the same machine.
- `get_tables` lists the tables the driver exposes, returned as CSV with a header row
- `get_columns` lists the columns on one of those tables, in the same CSV shape
- `run_query` executes a SQL SELECT against live Twitter Ads data
- Tool names carry the prefix you set in the property file — the sample config uses `Prefix=twitterads`
- Leaving `Tables=` blank exposes everything the driver can reach; naming tables there narrows it
Java and Maven: `mvn clean install` builds `CDataMCP-jar-with-dependencies.jar`. Separately install the CData JDBC Driver for Twitter Ads and license it by running `java -jar cdata.jdbc.twitterads.jar --license`, entering `TRIAL` or a license key. Build the connection string with the same jar, authenticating in the browser if the source uses OAuth, then write a `.prp` file naming the driver path, the driver class `cdata.jdbc.twitterads.TwitterAdsDriver` and that JDBC URL. Point your client at `java -jar` with the built jar and the `.prp` file.