The tool surface is deliberately tiny — list tables, list columns, run a SELECT — and that is what makes it predictable: the model discovers the schema before it writes SQL, so answers are grounded in the actual field names. The setup is the real cost, since the CData JDBC driver has to be installed and licensed separately before anything works.
A local MCP server that wraps the CData JDBC Driver for Epicor Kinetic, which presents Epicor Kinetic as relational SQL tables. The server hands a model those tables and a query tool, so questions get answered from live data instead of guessed at. It is read-only by design and speaks `stdio`, so it can only be used by a client running on the same machine.
- The list of Epicor Kinetic tables the driver exposes, returned as CSV with a header row — `epicorkinetic_get_tables`
- The columns of any one of those tables, so a model can build a query against real field names rather than invented ones — `epicorkinetic_get_columns`
- A SQL `SELECT` against your live Epicor Kinetic data — `epicorkinetic_run_query`
- Control over what is reachable at all: the `Tables` property in the connection file limits which tables get exposed, and leaving it blank exposes everything
An Epicor Kinetic account plus a licensed CData JDBC Driver for Epicor Kinetic — a trial licence works, entered by running `java -jar cdata.jdbc.epicorkinetic.jar --license`. Java to run the server and Maven to build it: `mvn clean install` produces `CDataMCP-jar-with-dependencies.jar`. You then write a `.prp` connection file naming `DriverClass` as `cdata.jdbc.epicorkinetic.EpicorKineticDriver`, the path to the driver jar, a tool `Prefix` such as `epicorkinetic`, and the JDBC connection string — the driver's Connection String utility builds that string for you, and OAuth sources authenticate in your browser during that step. MIT licensed.