The three-call shape — list tables, list columns, run a SELECT — is what lets a model find its own way to an answer, and the `Tables` setting in the property file is the lever that decides how much of DocuSign it can see. This build is read-only by design; CData points at their commercial server for write access.
A read-only MCP server that puts DocuSign behind a relational interface. It wraps the CData JDBC Driver for DocuSign, which models the service as SQL tables, and exposes table discovery plus a SELECT runner — so a natural-language question becomes a query the model composes and runs.
- `docusign_get_tables` — list the tables the driver exposes for the data source, returned as CSV with a header row
- `docusign_get_columns` — list the columns on one table, so the model knows what it can select before it writes a query
- `docusign_run_query` — execute a SQL SELECT and return the rows
- The tool prefix is whatever you set as `Prefix` in the connection property file, so several CData servers can sit in one client without colliding
A licensed CData JDBC Driver for DocuSign (a trial key works) and DocuSign credentials — OAuth authentication happens in your browser while building the connection string. Java, plus Maven 3 to build `CDataMCP-jar-with-dependencies.jar` with `mvn clean install`. You then write a `.prp` file naming `DriverPath`, `DriverClass`, `JdbcUrl` and an optional `Tables` allowlist, and the client launches `java -jar` against the jar and that file. It speaks stdio, so the server must 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