The work here is not in the tool surface — it is in the JDBC driver turning NetSuite's API into tables an LLM already knows how to query. Discovery, columns, SELECT: that is enough for a model to answer questions about data it has never seen. Two boundaries to know. This build is read-only and local, and CData points at their hosted platform for remote access and at their packaged MCP server for write, update and delete. The `Tables` property in the .prp file is the cheapest way to narrow what is exposed.
CData's read-only server for NetSuite. The CData JDBC Driver models NetSuite as relational SQL tables; this Java server wraps that driver so an LLM can discover the tables and query them without you writing SQL.
- `netsuite_get_tables` lists the tables available in the data source, returned as CSV with a header row
- `netsuite_get_columns` lists the columns for one table, same CSV shape
- `netsuite_run_query` executes a SQL SELECT
- The prefix is yours to set in the `.prp` file, so the tools appear as `netsuite_get_tables`, `netsuite_get_columns` and `netsuite_run_query`
- In practice you do not call them by hand — you ask a question about the data and the client picks the calls
Java and Maven: clone, `mvn clean install` to produce CDataMCP-jar-with-dependencies.jar. Separately install and license the CData JDBC Driver for NetSuite — running `java -jar cdata.jdbc.netsuite.jar --license` accepts a key or TRIAL, and running it without arguments opens the connection-string utility. Then write a `.prp` file with Prefix, ServerName, ServerVersion, DriverPath, DriverClass and JdbcUrl; leave Tables blank for everything or list the ones you want. Launch it as `java -jar CDataMCP-jar-with-dependencies.jar netsuite.prp`. It speaks stdio, so client and server must be on the same machine.