The query tool executes SELECT and nothing else, which is the right default for payroll and HR data. CData points elsewhere for anything more: their downloadable MCP server for full read-write-update-delete with a simpler setup, and CData Connect AI for a managed remote endpoint. The setup here is the honest cost — a licensed JDBC driver, a Maven build and a hand-written properties file — but if ADP already sits behind a CData driver in your stack, this reuses that connection rather than adding another integration.
A local, read-only MCP server from CData that wraps their JDBC driver for ADP. The driver presents ADP as relational SQL models; the server exposes three tools over that, so a model can discover the schema and run SELECT queries without anyone writing SQL by hand.
- `adp_get_tables` — the tables available in the data source, returned as CSV with a header row
- `adp_get_columns` — the columns on a named table, same CSV shape, so the model can check field names before querying
- `adp_run_query` — executes a SQL SELECT query against ADP
- Control over scope through the `Tables` property: leave it blank for everything, or name explicitly which tables get exposed
The CData JDBC Driver for ADP, downloaded separately and licensed — run `java -jar cdata.jdbc.adp.jar --license` and enter your name, email and either TRIAL or a licence key. Java to run the server and Maven to build it: `mvn clean install` produces `CDataMCP-jar-with-dependencies.jar`. Then write a `.prp` file naming `Prefix`, `ServerName`, `ServerVersion`, `DriverPath`, `DriverClass` (`cdata.jdbc.adp.ADPDriver`), the `JdbcUrl` built with the driver's connection-string utility, and `Tables`. The client launches java with the jar and the .prp path as arguments. Transport is stdio, so the server must run on the same machine as the client. MIT licensed.