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