The server itself is thin: it lists tables, lists columns, and runs SELECT statements. What makes it useful is the CData JDBC Driver for SendGrid underneath, which turns campaigns, contacts and delivery statistics into relational tables the model can join. That driver is a separate download and a separate licence, and it is the piece that decides which SendGrid data you can see.
A Java MCP server that puts CData's JDBC Driver for SendGrid behind three read-only tools: list the tables, list a table's columns, and run a SQL SELECT. The driver is what does the work — it exposes SendGrid as relational SQL models — and the server hands those models to your client so you can ask questions in plain language instead of writing SQL yourself.
- `get_tables` returns the tables available in the data source, as CSV with a header row
- `get_columns` returns the columns of one table, in the same CSV shape
- `run_query` executes a SQL SELECT and returns the rows
- Every tool name is prefixed with the server name from your `.prp` file, so several CData servers can run side by side without colliding
- Questions like "how many open tickets do I have" go straight to the client — it picks the tools and writes the SQL
Build the server with `mvn clean install`, which produces `CDataMCP-jar-with-dependencies.jar`. Separately download the CData JDBC Driver for SendGrid and license it: run `java -jar cdata.jdbc.sendgrid.jar --license` and enter your name, email and either `TRIAL` or a licence key. Then write a `.prp` file naming `DriverClass=cdata.jdbc.sendgrid.SendGridDriver` plus the `JdbcUrl` you build in the driver's connection-string utility, and point your client at `java -jar` with the jar and that file. Transport is stdio, so the server has to run on the same machine as the client.
Build from source — clone the repository and build it, then deploy it and point your client at the endpoint