Rather than modelling every Zoho Creator object as its own tool, this hands the assistant a schema and a query executor and lets SQL do the rest — which is why an unfamiliar question does not need a new tool. The trade is setup: a licensed JDBC driver, a Maven build and a hand-written properties file stand between you and the first query. Two limits worth naming: this build is read-only, and the tables property is the only place to narrow what the assistant can reach.
A local, read-only MCP server built by CData that wraps their JDBC driver for Zoho Creator. The driver presents Zoho Creator as relational SQL models; the server puts a small tool surface in front of it so an assistant can find the tables, inspect their columns, and answer questions in natural language without you writing the query.
- The list of tables available in the data source, returned as CSV with a header row — `get_tables`
- The columns of one table, so a query can be built against the real schema rather than a guessed one — `get_columns`
- SQL SELECT execution against the connected source — `run_query`
- All three carry the prefix you set in the connection properties file, so several CData servers can run side by side without their tool names colliding
A Zoho Creator account and the CData JDBC Driver for Zoho Creator, downloaded and licensed separately — the driver JAR is run once with `--license` and takes your name, email and either TRIAL or a license key. Java, plus Maven to build the server JAR from a clone. Connection details go in a properties file listing the tool prefix, the server name and version, the driver JAR path, the driver class, and the JDBC URL — you generate that URL with the driver's own connection-string utility, authenticating in the browser when the source uses OAuth. Leaving the tables property blank exposes everything; naming tables restricts access to those. The client entry runs java with the built JAR and your properties file. Transport is stdio, so client and server must be on the same machine.