Summary

A mailbox you can query, not one it can act on.

Mail is one of the riskiest things to hand an assistant, and the design here removes the part that worries people: the tools are table discovery and a SELECT, so it can read and summarise but has no way to send, delete or move anything. Messages and labels arrive as rows, which makes questions like what is still unanswered from last week a query rather than a scroll. Setup is a Maven build, a licensed driver install and a browser OAuth sign-in while building the connection string.

What it is

A local, read-only bridge between an assistant and Gmail. CData's JDBC driver exposes Gmail as relational SQL models; this server wraps the driver so a model can discover the tables and query them, and you can ask in plain language instead of writing SQL. It runs over stdio, so the client has to be on the same machine.

What you get

`get_tables` lists the tables the driver exposes, returned as CSV with a header row
`get_columns` lists the columns on one of those tables, in the same CSV shape
`run_query` executes a SQL SELECT against live Gmail data
Tool names carry the prefix you set in the property file — the sample config uses `Prefix=gmail`
Leaving `Tables=` blank exposes everything the driver can reach; naming tables there narrows it

Requirements

Java and Maven: `mvn clean install` builds `CDataMCP-jar-with-dependencies.jar`. Separately install the CData JDBC Driver for Gmail and license it by running `java -jar cdata.jdbc.gmail.jar --license`, entering `TRIAL` or a license key. Build the connection string with the same jar, authenticating in the browser if the source uses OAuth, then write a `.prp` file naming the driver path, the driver class `cdata.jdbc.gmail.GmailDriver` and that JDBC URL. Point your client at `java -jar` with the built jar and the `.prp` file.

Setup effort

Build from source — clone the repository and build it, then deploy it and point your client at the endpoint