Trino MCP Server
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| TRINO_HOST | No | Trino server hostname | localhost |
| TRINO_PORT | No | Trino server port (auto-set to 443 for OAuth2/Azure SPN) | 8080 |
| TRINO_USER | No | Username | trino |
| AUTH_METHOD | No | Authentication method: NONE, PASSWORD, OAUTH2, or AZURE_SPN | NONE |
| AZURE_SCOPE | No | Azure token scope for AZURE_SPN auth | |
| TRINO_SCHEMA | No | Default schema | |
| TRINO_CATALOG | No | Default catalog | |
| TRINO_PASSWORD | No | Password for PASSWORD auth | |
| AZURE_CLIENT_ID | No | Azure client ID for AZURE_SPN auth | |
| AZURE_TENANT_ID | No | Azure tenant ID for AZURE_SPN auth | |
| TRINO_HTTP_SCHEME | No | http or https (auto-set to https for OAuth2/Azure SPN) | http |
| ALLOW_WRITE_QUERIES | No | Enable write operations (true, 1, or yes) | false |
| AZURE_CLIENT_SECRET | No | Azure client secret for AZURE_SPN auth | |
| QUERY_TIMEOUT_MINUTES | No | Client-side query timeout in minutes (0 to disable) | 5 |
| MAX_CONCURRENT_QUERIES | No | Max concurrent tool calls | 1 |
| TRINO_SESSION_PROPERTIES | No | JSON object of Trino session properties | |
| TRINO_MCP_CUSTOM_WATERMARK | No | JSON object for custom query watermark |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| list_catalogsA | List all available Trino catalogs. |
| list_schemasA | List all schemas in a catalog. Args: catalog: The name of the catalog to list schemas from |
| list_tablesA | List all tables in a schema. Args: catalog: The name of the catalog schema: The name of the schema |
| describe_tableB | Describe the structure of a table (columns, types, etc). Args: table: The table name (e.g. 'my_table'). Preferably just the table name; catalog and schema should be passed as separate parameters. Fully qualified names like 'catalog.schema.table' are also accepted. catalog: The catalog name (optional if default is configured) schema: The schema name (optional if default is configured) |
| execute_query_read_onlyA | Execute a read-only SQL query and return the results. This tool is designed for read-only queries (SELECT, SHOW, DESCRIBE, EXPLAIN, etc.). It validates that the query is read-only before execution. When output_file is provided, results are written directly to disk and only a confirmation message is returned. This prevents raw data from passing through the AI, avoiding hallucination when processing large result sets. The output format (JSON or CSV) is derived from the file extension. Args: query: The SQL query to execute (must be read-only) output_file: File path to write results to. Extension determines format (.csv → CSV, .json or others → JSON). Results are NOT returned to the AI, enabling reliable downstream processing. |
| execute_queryA | Execute a SQL query and return the results. This tool can execute any SQL query including write operations (INSERT, UPDATE, DELETE, etc.). By default, write operations are disabled for security. Set ALLOW_WRITE_QUERIES=true to enable. When output_file is provided, results are written directly to disk and only a confirmation message is returned. This prevents raw data from passing through the AI, avoiding hallucination when processing large result sets. The output format (JSON or CSV) is derived from the file extension. Args: query: The SQL query to execute output_file: File path to write results to. Extension determines format (.csv → CSV, .json or others → JSON). Results are NOT returned to the AI, enabling reliable downstream processing. |
| show_create_tableA | Show the CREATE TABLE statement for a table. Args: table: The table name (e.g. 'my_table'). Preferably just the table name; catalog and schema should be passed as separate parameters. Fully qualified names like 'catalog.schema.table' are also accepted. catalog: The catalog name (optional if default is configured) schema: The schema name (optional if default is configured) |
| get_table_statsB | Get statistics for a table. Args: table: The table name (e.g. 'my_table'). Preferably just the table name; catalog and schema should be passed as separate parameters. Fully qualified names like 'catalog.schema.table' are also accepted. catalog: The catalog name (optional if default is configured) schema: The schema name (optional if default is configured) |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 8 tools
Most tools have clear, distinct purposes: listing catalogs/schemas/tables, getting table metadata, and executing queries. The two query execution tools are differentiated by read-only vs. write-capable, and describe_table vs. show_create_table both deal with table structure but with different outputs. Minor overlap exists but descriptions resolve ambiguity.
All tool names follow a consistent verb_noun pattern (list_*, describe_table, execute_query, show_create_table, get_table_stats), using lowercase snake_case throughout. The read-only query tool is named as a clear modifier of execute_query, maintaining consistency.
The 8 tools are well-scoped for a Trino query server, covering metadata exploration and query execution without redundancy. The count is within the ideal 3-15 range and each tool serves a specific need.
The tool surface covers the primary use cases: discovering catalogs/schemas/tables, inspecting table structure, retrieving table statistics, and running read-only or write queries. Minor gaps exist, such as lack of explicit query cancellation or history, but these are not critical for typical Trino interactions and can be handled via SQL.