The usual path to analysing responses is downloading a CSV and losing the connection to the live data; querying the source directly means the answer reflects what came in this morning. Because the interface is SQL rather than one tool per object, questions nobody anticipated still work. Two limits to keep in view: this build reads only, and the tables property is where you narrow what an assistant can reach.
A local, read-only MCP server built by CData that wraps their JDBC driver for SurveyMonkey. The driver presents SurveyMonkey as relational SQL models; the server exposes a small tool surface so an assistant can discover the tables, inspect columns, and answer questions about survey data without you hand-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 is built against the real schema — `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 colliding tool names
A SurveyMonkey account and the CData JDBC Driver for SurveyMonkey, 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, server name and version, the driver JAR path, the driver class, and the JDBC URL generated by the driver's connection-string utility; OAuth sources authenticate in the browser at that step. Leaving the tables property blank exposes everything, naming tables restricts it. The client entry runs java with the built JAR and the properties file, over stdio, so client and server share a machine.