Campaign platforms are where 'can you pull the numbers for last quarter' turns into an afternoon of exports. Putting the account behind SQL lets the assistant answer that directly, and restricting it to SELECT means a wrong query wastes a moment rather than changing a list. The driver licence and the Maven build are a real up-front cost; CData's paid products are where the write path lives, so plan this one as reporting.
A local, read-only MCP server that exposes ActiveCampaign as a relational SQL model. It wraps CData's JDBC driver for ActiveCampaign, so contacts, campaigns and the rest of the account's objects appear as tables an assistant can discover and query in response to plain-language questions.
- The tables available in ActiveCampaign, returned as CSV with a header row — `get_tables`
- The columns on a chosen table, so a query can be written against real column names — `get_columns`
- A SQL SELECT executed against live ActiveCampaign data — `run_query`
- Tool names prefixed with the server name from your properties file, so multiple CData servers coexist in one client
- A `Tables` property that restricts which tables are exposed at all
An ActiveCampaign account, plus CData's JDBC driver for ActiveCampaign downloaded and licensed separately — `java -jar cdata.jdbc.activecampaign.jar --license` takes your name, email and TRIAL or a license key. Java and Maven: `mvn clean install` builds the runnable JAR. Then a `.prp` file with the prefix, server name and version, the driver JAR path, the driver class `cdata.jdbc.activecampaign.ActiveCampaignDriver`, and the JDBC connection string from the driver's connection-string utility. The client entry runs java with the JAR and the `.prp` path. Communication is over stdio, so the client must run on the same machine. MIT licensed.