Basecamp is organised around browsing one project at a time, which makes "what is overdue across everything" a manual count. A SQL interface over the same data turns that into one query, and because the shape is tables rather than one tool per object, questions nobody planned for still work. Two limits to keep in view: this build reads only, and the tables property is the only place to narrow what an assistant can reach.
A local, read-only MCP server built by CData that wraps their JDBC driver for Basecamp. The driver presents Basecamp as relational SQL models; the server puts three tools in front of it so an assistant can discover the tables, inspect their columns, and answer questions without you writing the query by hand.
- 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 rather than a guess — `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 Basecamp account and the CData JDBC Driver for Basecamp, 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 naming the tool prefix, the server name and version, the driver JAR path, the driver class and the JDBC URL, which you generate with the driver's own connection-string utility and authenticate in the browser when the source uses OAuth. 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.
Build from source — clone the repository and build it, then point your client at the binary