LabscoMCP early access ↗
tuannvmMCP SERVER

Trino MCP Server in Go

Query a Trino cluster and walk its catalogs from an assistant, with allowlists to keep it inside the schemas that matter.

by tuannvm ↗Relational SQL DatabasesCommunity

LABSCO SUMMARY

Discovery first, then the query.

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.

What it is

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.

What you get

  • 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

Requirements

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.

Setup effort

One command plus credentials — brew install tuannvm/mcp/mcp-trino, then supply credentials