Turning Adobe Analytics into SQL models is what makes a natural-language question answerable at all — the assistant discovers the tables and columns, then writes one SELECT. This build is the reading half of CData's stack by design; write access and the managed remote option are separate products. The `Tables` property in the connection file is the control worth using: name the permitted tables and the rest never becomes reachable.
A local, read-only MCP server from CData that wraps the CData JDBC Driver for Adobe Analytics. The driver presents Adobe Analytics as relational SQL models; the server exposes three tools over that connection, so an assistant can answer questions about live analytics data without anyone writing SQL by hand.
- The list of tables the driver exposes for your Adobe Analytics connection, returned as CSV with a header row — `adobeanalytics_get_tables`
- Column listings for any of those tables, also as CSV with headers — `adobeanalytics_get_columns`
- SQL SELECT execution against the live connection — `adobeanalytics_run_query`
- A `Tables` entry in the connection file that limits which tables are exposed at all
A licensed CData JDBC Driver for Adobe Analytics — run `java -jar cdata.jdbc.adobeanalytics.jar --license` and enter TRIAL or your key. Java and Maven, since the server is built with `mvn clean install` into CDataMCP-jar-with-dependencies.jar. A `.prp` file carrying Prefix, ServerName, ServerVersion, DriverPath, DriverClass and JdbcUrl, passed to the jar as its argument. Adobe Analytics authenticates over OAuth, so the first connection is completed in a browser. Transport is stdio, so the client must run on the same machine as the server.
Build from source — clone the repository and build it, then point your client at the binary