The four listing tools exist so an assistant finds the right catalog, schema and table before it writes any SQL, and the plan tool lets it read what a query will do before the cluster spends time on it. On a large deployment the allowlist variables are what make that workable — restrict it to the handful of schemas that matter and it stops wandering through catalogs nobody asked about.
A Go MCP server for Trino, the distributed SQL query engine formerly called PrestoSQL. The same binary doubles as an interactive CLI in the shape of psql. It runs over STDIO or Streamable HTTP, with SSE endpoints kept for backward compatibility, and optional OAuth 2.1 through the oauth-mcp-proxy library with HMAC, Okta, Google and Azure AD as providers.
- SQL run against Trino with the columns and rows returned as structured data — `execute_query`
- Discovery down the hierarchy so the model finds the right table before writing SQL — `list_catalogs`, `list_schemas`, `list_tables`, `get_table_schema`, the last returning column names, types and nullability
- A query's distributed execution plan with stages and estimated rows and cost, read without running the query — `explain_query`
- An interactive CLI on the same binary: `mcp-trino --interactive` for a REPL, `mcp-trino query` to run one statement, plus `catalogs`, `schemas`, `tables`, `describe` and `explain` subcommands, with output as `table` (the default), `json` or `csv`
- REPL meta-commands for the same moves — `\catalogs`, `\schemas`, `\tables`, `\describe`, `\format`, `\history`
- Named connection profiles in `~/.config/trino/config.yaml` or `config.json`, switched with `mcp-trino config profile use prod` or per-command with `--profile dev`; when both files exist the JSON one wins
- Allowlists that shrink what the assistant can even see, at catalog, schema and table level, case-insensitive and independent of each other — `TRINO_ALLOWED_CATALOGS`, `TRINO_ALLOWED_SCHEMAS`, `TRINO_ALLOWED_TABLES`
- Query attribution: with OAuth enabled, queries are automatically tagged with the OAuth user through the `X-Trino-Client-Tags` and `X-Trino-Client-Info` headers, and opt-in impersonation sends `X-Trino-User` so Trino applies that user's own permissions — `TRINO_ENABLE_IMPERSONATION`, `TRINO_IMPERSONATION_FIELD`
- Exit codes worth scripting against: `0` success, `1` runtime error such as a failed connection or query, `2` usage error
- Distribution as a Homebrew formula, an install script and a Docker image on GitHub Container Registry, with SBOM and SLSA provenance published per release
A reachable Trino cluster and its connection details in the environment: `TRINO_HOST`, `TRINO_PORT`, `TRINO_USER`, `TRINO_PASSWORD`, `TRINO_CATALOG`, `TRINO_SCHEMA` and `TRINO_SSL`; a local development run needs only `TRINO_HOST` and `TRINO_USER`. Install with `brew install tuannvm/mcp/mcp-trino` or the install script from the repository. Secrets are read purely from the process environment, and the README's recommended pattern is injecting them at launch from a secrets CLI such as 1Password or Vault rather than writing them to disk. OAuth is optional: `OAUTH_ENABLED`, `OAUTH_MODE` (`native` keeps all secrets on the client side, `proxy` centralises them on the server), `OAUTH_PROVIDER`, `OIDC_ISSUER` and `OIDC_AUDIENCE`, with `OIDC_CLIENT_ID`, `OIDC_CLIENT_SECRET` and `OAUTH_REDIRECT_URI` added in proxy mode; `JWT_SECRET` is required for multi-pod deployments. MIT licensed.
One command plus a key — brew install tuannvm/mcp/mcp-trino, then supply credentials