Skip to main content
Glama
enesjakozh
stinkgen

Trino MCP Server

by stinkgen
OverviewSchemaRelated ServersScoreDiscussions
Python
Hybrid

Trino MCP Server

Model Context Protocol server for Trino, providing AI models with structured access to Trino's distributed SQL query engine.

⚠️ BETA RELEASE (v0.1.2) ⚠️
This project is stabilizing with core features working and tested. Feel free to fork and contribute!

Features

  • ✅ Fixed Docker container API initialization issue! (reliable server initalization)

  • ✅ Exposes Trino resources through MCP protocol

  • ✅ Enables AI tools to query and analyze data in Trino

  • ✅ Provides transport options (STDIO transport works reliably; SSE transport has issues)

  • ✅ Fixed catalog handling for proper Trino query execution

  • ✅ Both Docker container API and standalone Python API server options

Related MCP server: Trino MCP Server

Quick Start

# Start the server with docker-compose
docker-compose up -d

# Verify the API is working
curl -X POST "http://localhost:9097/api/query" \
     -H "Content-Type: application/json" \
     -d '{"query": "SELECT 1 AS test"}'

Need a non-containerized version? Run the standalone API:

# Run the standalone API server on port 8008
python llm_trino_api.py

LLM Integration

Want to give an LLM direct access to query your Trino instance? We've created simple tools for that!

Command-Line LLM Interface

The simplest way to let an LLM query Trino is through our command-line tool:

# Simple direct query (perfect for LLMs)
python llm_query_trino.py "SELECT * FROM memory.bullshit.real_bullshit_data LIMIT 5"

# Specify a different catalog or schema
python llm_query_trino.py "SELECT * FROM information_schema.tables" memory information_schema

REST API for LLMs

We offer two API options for integration with LLM applications:

1. Docker Container API (Port 9097)

The Docker container exposes a REST API on port 9097:

# Execute a query against the Docker container API
curl -X POST "http://localhost:9097/api/query" \
     -H "Content-Type: application/json" \
     -d '{"query": "SELECT 1 AS test"}'

2. Standalone Python API (Port 8008)

For more flexible deployments, run the standalone API server:

# Start the API server on port 8008
python llm_trino_api.py

This creates endpoints at:

  • GET http://localhost:8008/ - API usage info

  • POST http://localhost:8008/query - Execute SQL queries

You can then have your LLM make HTTP requests to this endpoint:

# Example code an LLM might generate
import requests

def query_trino(sql_query):
    response = requests.post(
        "http://localhost:8008/query",
        json={"query": sql_query}
    )
    return response.json()

# LLM-generated query
results = query_trino("SELECT job_title, AVG(salary) FROM memory.bullshit.real_bullshit_data GROUP BY job_title ORDER BY AVG(salary) DESC LIMIT 5")
print(results["formatted_results"])

This approach allows LLMs to focus on generating SQL, while our tools handle all the MCP protocol complexity!

Demo and Validation Scripts 🚀

We've created some badass demo scripts that show how AI models can use the MCP protocol to run complex queries against Trino:

1. Bullshit Data Generation and Loading

The tools/create_bullshit_data.py script generates a dataset of 10,000 employees with ridiculous job titles, inflated salaries, and a "bullshit factor" rating (1-10):

# Generate the bullshit data
python tools/create_bullshit_data.py

# Load the bullshit data into Trino's memory catalog
python load_bullshit_data.py

2. Running Complex Queries through MCP

The test_bullshit_query.py script demonstrates end-to-end MCP interaction:

  • Connects to the MCP server using STDIO transport

  • Initializes the protocol following the MCP spec

  • Runs a complex SQL query with WHERE, GROUP BY, HAVING, ORDER BY

  • Processes and formats the results

# Run a complex query against the bullshit data through MCP
python test_bullshit_query.py

Example output showing top BS jobs with high salaries:

🏆 TOP 10 BULLSHIT JOBS (high salary, high BS factor):
----------------------------------------------------------------------------------------------------
JOB_TITLE             | COUNT                | AVG_SALARY           | MAX_SALARY           | AVG_BS_FACTOR        
----------------------------------------------------------------------------------------------------
Advanced Innovation Jedi | 2                    |            241178.50 |            243458.00 |                 7.50
VP of Digital Officer | 1                    |            235384.00 |            235384.00 |                 7.00
Innovation Technical Architect | 1                    |            235210.00 |            235210.00 |                 9.00
...and more!

3. API Testing

The test_llm_api.py script validates the API functionality:

# Test the Docker container API 
python test_llm_api.py

This performs a comprehensive check of:

  • API endpoint discovery

  • Documentation availability

  • Valid query execution

  • Error handling for invalid queries

Usage

# Start the server with docker-compose
docker-compose up -d

The server will be available at:

Client Connection

✅ IMPORTANT: The client scripts run on your local machine (OUTSIDE Docker) and connect TO the Docker containers. The scripts automatically handle this by using docker exec commands. You don't need to be inside the container to use MCP!

Running tests from your local machine:

# Generate and load data into Trino
python tools/create_bullshit_data.py  # Generates data locally
python load_bullshit_data.py          # Loads data to Trino in Docker

# Run MCP query through Docker
python test_bullshit_query.py         # Queries using MCP in Docker

Transport Options

This server supports two transport methods, but only STDIO is currently reliable:

STDIO Transport (Recommended and Working)

STDIO transport works reliably and is currently the only recommended method for testing and development:

# Run with STDIO transport inside the container
docker exec -i trino_mcp_trino-mcp_1 python -m trino_mcp.server --transport stdio --debug --trino-host trino --trino-port 8080 --trino-user trino --trino-catalog memory

SSE Transport (NOT RECOMMENDED - Has Critical Issues)

SSE is the default transport in MCP but has serious issues with the current MCP 1.3.0 version, causing server crashes on client disconnections. Not recommended for use until these issues are resolved:

# NOT RECOMMENDED: Run with SSE transport (crashes on disconnection)
docker exec trino_mcp_trino-mcp_1 python -m trino_mcp.server --transport sse --host 0.0.0.0 --port 8000 --debug

Known Issues and Fixes

Fixed: Docker Container API Initialization

✅ FIXED: We've resolved an issue where the API in the Docker container returned 503 Service Unavailable responses. The problem was with the app_lifespan function not properly initializing the app_context_global and Trino client connection. The fix ensures that:

  1. The Trino client explicitly connects during startup

  2. The AppContext global variable is properly initialized

  3. Health checks now work correctly

If you encounter 503 errors, check that your container has been rebuilt with the latest code:

# Rebuild and restart the container with the fix
docker-compose stop trino-mcp
docker-compose rm -f trino-mcp
docker-compose up -d trino-mcp

MCP 1.3.0 SSE Transport Crashes

There's a critical issue with MCP 1.3.0's SSE transport that causes server crashes when clients disconnect. Until a newer MCP version is integrated, use STDIO transport exclusively. The error manifests as:

RuntimeError: generator didn't stop after athrow()
anyio.BrokenResourceError

Trino Catalog Handling

We fixed an issue with catalog handling in the Trino client. The original implementation attempted to use USE catalog statements, which don't work reliably. The fix directly sets the catalog in the connection parameters.

Project Structure

This project is organized as follows:

  • src/ - Main source code for the Trino MCP server

  • examples/ - Simple examples showing how to use the server

  • scripts/ - Useful diagnostic and testing scripts

  • tools/ - Utility scripts for data creation and setup

  • tests/ - Automated tests

Key files:

  • llm_trino_api.py - Standalone API server for LLM integration

  • test_llm_api.py - Test script for the API server

  • test_mcp_stdio.py - Main test script using STDIO transport (recommended)

  • test_bullshit_query.py - Complex query example with bullshit data

  • load_bullshit_data.py - Script to load generated data into Trino

  • tools/create_bullshit_data.py - Script to generate hilarious test data

  • run_tests.sh - Script to run automated tests

  • examples/simple_mcp_query.py - Simple example to query data using MCP

Development

IMPORTANT: All scripts can be run from your local machine - they'll automatically communicate with the Docker containers via docker exec commands!

# Install development dependencies
pip install -e ".[dev]"

# Run automated tests 
./run_tests.sh

# Test MCP with STDIO transport (recommended)
python test_mcp_stdio.py

# Simple example query
python examples/simple_mcp_query.py "SELECT 'Hello World' AS message"

Testing

To test that Trino queries are working correctly, use the STDIO transport test script:

# Recommended test method (STDIO transport)
python test_mcp_stdio.py

For more complex testing with the bullshit data:

# Load and query the bullshit data (shows the full power of Trino MCP!)
python load_bullshit_data.py
python test_bullshit_query.py

For testing the LLM API endpoint:

# Test the Docker container API
python test_llm_api.py 

# Test the standalone API (make sure it's running first)
python llm_trino_api.py
curl -X POST "http://localhost:8008/query" \
     -H "Content-Type: application/json" \
     -d '{"query": "SELECT 1 AS test"}'

How LLMs Can Use This

LLMs can use the Trino MCP server to:

  1. Get Database Schema Information:

    # Example prompt to LLM: "What schemas are available in the memory catalog?"
# LLM can generate code to query:
query = "SHOW SCHEMAS FROM memory"

  2. Run Complex Analytical Queries:

    # Example prompt: "Find the top 5 job titles with highest average salaries"
# LLM can generate complex SQL:
query = """
SELECT 
  job_title, 
  AVG(salary) as avg_salary
FROM 
  memory.bullshit.real_bullshit_data
GROUP BY 
  job_title
ORDER BY 
  avg_salary DESC
LIMIT 5
"""

  3. Perform Data Analysis and Present Results:

    # LLM can parse the response, extract insights and present to user:
"The highest paying job title is 'Advanced Innovation Jedi' with an average salary of $241,178.50"

Real LLM Analysis Example: Bullshit Jobs by Company

Here's a real example of what an LLM could produce when asked to "Identify the companies with the most employees in bullshit jobs and create a Mermaid chart":

Step 1: LLM generates and runs the query

SELECT 
  company, 
  COUNT(*) as employee_count, 
  AVG(bullshit_factor) as avg_bs_factor 
FROM 
  memory.bullshit.real_bullshit_data 
WHERE 
  bullshit_factor > 7 
GROUP BY 
  company 
ORDER BY 
  employee_count DESC, 
  avg_bs_factor DESC 
LIMIT 10

Step 2: LLM gets and analyzes the results

COMPANY | EMPLOYEE_COUNT | AVG_BS_FACTOR
----------------------------------------
Unknown Co | 2 | 9.0
BitEdge | 1 | 10.0
CyberWare | 1 | 10.0
BitLink | 1 | 10.0
AlgoMatrix | 1 | 10.0
CryptoHub | 1 | 10.0
BitGrid | 1 | 10.0
MLStream | 1 | 10.0
CloudCube | 1 | 10.0
UltraEdge | 1 | 10.0

Step 3: LLM generates a Mermaid chart visualization

%%{init: {'theme': 'forest'}}%%
graph LR
    title[Companies with Most Bullshit Jobs]
    style title fill:#333,stroke:#333,stroke-width:1px,color:white,font-weight:bold,font-size:18px

    Companies --> UnknownCo[Unknown Co]
    Companies --> BitEdge[BitEdge]
    Companies --> CyberWare[CyberWare]
    Companies --> BitLink[BitLink]
    Companies --> AlgoMatrix[AlgoMatrix]
    Companies --> CryptoHub[CryptoHub]
    Companies --> BitGrid[BitGrid]
    Companies --> MLStream[MLStream]
    Companies --> CloudCube[CloudCube]
    Companies --> UltraEdge[UltraEdge]
    
    UnknownCo --- Count2[2 employees]
    BitEdge --- Count1a[1 employee]
    CyberWare --- Count1b[1 employee]
    BitLink --- Count1c[1 employee]
    AlgoMatrix --- Count1d[1 employee]
    CryptoHub --- Count1e[1 employee]
    BitGrid --- Count1f[1 employee]
    MLStream --- Count1g[1 employee]
    CloudCube --- Count1h[1 employee]
    UltraEdge --- Count1i[1 employee]
    
    classDef company fill:#ff5733,stroke:#333,stroke-width:1px,color:white,font-weight:bold;
    classDef count fill:#006100,stroke:#333,stroke-width:1px,color:white,font-weight:bold;
    
    class UnknownCo,BitEdge,CyberWare,BitLink,AlgoMatrix,CryptoHub,BitGrid,MLStream,CloudCube,UltraEdge company;
    class Count2,Count1a,Count1b,Count1c,Count1d,Count1e,Count1f,Count1g,Count1h,Count1i count;

Alternative Bar Chart:

%%{init: {'theme': 'default'}}%%
pie showData
    title Companies with Bullshit Jobs
    "Unknown Co (BS: 9.0)" : 2
    "BitEdge (BS: 10.0)" : 1
    "CyberWare (BS: 10.0)" : 1
    "BitLink (BS: 10.0)" : 1
    "AlgoMatrix (BS: 10.0)" : 1
    "CryptoHub (BS: 10.0)" : 1
    "BitGrid (BS: 10.0)" : 1
    "MLStream (BS: 10.0)" : 1
    "CloudCube (BS: 10.0)" : 1
    "UltraEdge (BS: 10.0)" : 1

Step 4: LLM provides key insights

The LLM can analyze the data and provide insights:

  • "Unknown Co" has the most employees in bullshit roles (2), while all others have just one

  • Most companies have achieved a perfect 10.0 bullshit factor score

  • Tech-focused companies (BitEdge, CyberWare, etc.) seem to create particularly meaningless roles

  • Bullshit roles appear concentrated at executive or specialized position levels

This example demonstrates how an LLM can:

  1. Generate appropriate SQL queries based on natural language questions

  2. Process and interpret the results from Trino

  3. Create visual representations of the data

  4. Provide meaningful insights and analysis

Accessing the API

The Trino MCP server now includes two API options for accessing data:

1. Docker Container API (Port 9097)

import requests
import json

# API endpoint (default port 9097 in Docker setup)
api_url = "http://localhost:9097/api/query"

# Define your SQL query
query_data = {
    "query": "SELECT * FROM memory.bullshit.real_bullshit_data LIMIT 5",
    "catalog": "memory",
    "schema": "bullshit"
}

# Send the request
response = requests.post(api_url, json=query_data)
results = response.json()

# Process the results
if results["success"]:
    print(f"Query returned {results['results']['row_count']} rows")
    for row in results['results']['rows']:
        print(row)
else:
    print(f"Query failed: {results['message']}")

2. Standalone Python API (Port 8008)

# Same code as above, but with different port
api_url = "http://localhost:8008/query"

Both APIs offer the following endpoints:

  • GET /api - API documentation and usage examples

  • POST /api/query - Execute SQL queries against Trino

These APIs eliminate the need for wrapper scripts and let LLMs query Trino directly using REST calls, making it much simpler to integrate with services like Claude, GPT, and other AI systems.

Troubleshooting

API Returns 503 Service Unavailable

If the Docker container API returns 503 errors:

  1. Make sure you've rebuilt the container with the latest code:

    docker-compose stop trino-mcp
docker-compose rm -f trino-mcp
docker-compose up -d trino-mcp

  2. Check the container logs for errors:

    docker logs trino_mcp_trino-mcp_1

  3. Verify that Trino is running properly:

    curl -s http://localhost:9095/v1/info | jq

Port Conflicts with Standalone API

The standalone API defaults to port 8008 to avoid conflicts. If you see an "address already in use" error:

  1. Edit llm_trino_api.py and change the port number in the last line:

    uvicorn.run(app, host="127.0.0.1", port=8008)

  2. Run with a custom port via command line:

    python -c "import llm_trino_api; import uvicorn; uvicorn.run(llm_trino_api.app, host='127.0.0.1', port=8009)"

Future Work

This is now in beta with these improvements planned:

  • Integrate with newer MCP versions when available to fix SSE transport issues

  • Add/Validate support for Hive, JDBC, and other connectors

  • Add more comprehensive query validation across different types and complexities

  • Implement support for more data types and advanced Trino features

  • Improve error handling and recovery mechanisms

  • Add user authentication and permission controls

  • Create more comprehensive examples and documentation

  • Develop admin monitoring and management interfaces

  • Add performance metrics and query optimization hints

  • Implement support for long-running queries and result streaming

Developed by Stink Labs, 2025

Available Tools

3 tools
cancel_queryC
    Cancel a running query.
    
    Args:
        query_id: ID of the query to cancel.
        
    Returns:
        Dict[str, Any]: Result of the cancellation operation.
ParametersJSON Schema
NameRequiredDescriptionDefault
query_idYes

TDQS

C2.9/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries full burden for behavioral disclosure. It states the action ('Cancel') but doesn't explain what cancellation entails (e.g., whether it's reversible, if it requires specific permissions, potential side effects, or rate limits). This leaves significant gaps in understanding the tool's behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is appropriately brief and front-loaded with the core purpose. The Args/Returns sections are structured but slightly verbose for a single parameter; every sentence earns its place, though minor trimming could improve efficiency.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the complexity of a cancellation operation (a mutation with potential side effects), no annotations, no output schema, and low schema coverage, the description is incomplete. It lacks details on behavioral traits, return value specifics, error conditions, and usage context, making it inadequate for safe and effective tool invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The description adds minimal semantic context for the single parameter ('ID of the query to cancel'), but with 0% schema description coverage, it doesn't fully compensate. It clarifies that 'query_id' refers to a query ID, which is helpful, but doesn't provide format examples or validation rules beyond what the basic schema indicates.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('Cancel') and target ('a running query'), providing a specific verb+resource combination. However, it doesn't differentiate from sibling tools like 'execute_query' or 'inspect_table', which would require explicit comparison to achieve a score of 5.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., that the query must be running), exclusions, or comparisons to sibling tools, leaving the agent without contextual usage instructions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

execute_queryB
    Execute a SQL query against Trino.
    
    Args:
        sql: The SQL query to execute.
        catalog: Optional catalog name to use for the query.
        schema: Optional schema name to use for the query.
        
    Returns:
        Dict[str, Any]: Query results including metadata.
ParametersJSON Schema
NameRequiredDescriptionDefault
sqlYes
catalogNo
schemaNo

TDQS

B3.1/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the action ('Execute a SQL query') and return type ('Dict[str, Any]: Query results including metadata'), but lacks critical details like permissions required, whether queries are read-only or mutating, timeouts, error handling, or rate limits. For a tool with no annotations, this is insufficient.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured and appropriately sized. It starts with a clear purpose statement, followed by bullet-like sections for 'Args' and 'Returns'. Each sentence adds value without redundancy, though the 'Returns' section could be more specific given the lack of an output schema.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (executing SQL queries), lack of annotations, and no output schema, the description is moderately complete. It covers the basic purpose and parameters but misses behavioral context (e.g., safety, performance) and detailed return value explanation. It's adequate as a starting point but has clear gaps for effective agent use.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The description adds significant value beyond the input schema, which has 0% description coverage. It explains each parameter's purpose: 'sql: The SQL query to execute', 'catalog: Optional catalog name to use for the query', and 'schema: Optional schema name to use for the query'. This clarifies semantics that the schema alone doesn't provide, though it doesn't detail format constraints or examples.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: 'Execute a SQL query against Trino.' This specifies the verb ('Execute') and resource ('SQL query'), and identifies the target system ('Trino'). However, it doesn't explicitly differentiate from sibling tools like 'cancel_query' or 'inspect_table' beyond the core action.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools ('cancel_query', 'inspect_table'), suggest prerequisites, or outline scenarios where this tool is appropriate versus others. Usage is implied only by the tool's name and purpose.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

inspect_tableC
    Get detailed metadata about a table.
    
    Args:
        catalog: Catalog name.
        schema: Schema name.
        table: Table name.
        
    Returns:
        Dict[str, Any]: Table metadata including columns, statistics, etc.
ParametersJSON Schema
NameRequiredDescriptionDefault
catalogYes
schemaYes
tableYes

TDQS

C2.9/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool retrieves metadata, implying a read-only operation, but doesn't specify permissions required, rate limits, error handling, or what 'detailed metadata' includes beyond a vague mention of 'columns, statistics, etc.' This leaves significant gaps in understanding the tool's behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured and concise, using a clear purpose statement followed by Args and Returns sections. Every sentence serves a purpose without unnecessary elaboration, making it easy to parse quickly.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the complexity of a metadata inspection tool with no annotations, no output schema, and low schema coverage, the description is incomplete. It lacks details on return format specifics, error cases, or behavioral traits, which are crucial for an agent to use the tool effectively in a database context.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The description lists the parameters (catalog, schema, table) and their roles, but with 0% schema description coverage, it only provides basic names without deeper context like format examples or constraints. It adds some value by clarifying what each parameter represents, but doesn't fully compensate for the lack of schema details.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose with a specific verb ('Get') and resource ('detailed metadata about a table'), making it easy to understand what the tool does. However, it doesn't explicitly differentiate from sibling tools like 'cancel_query' or 'execute_query', which might also interact with tables in different ways.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention any prerequisites, context for usage, or comparisons with sibling tools like 'cancel_query' or 'execute_query', leaving the agent to infer usage scenarios.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

B3.3/5.0
Disambiguation5/5

Each tool has a clearly distinct purpose with no overlap: cancel_query stops queries, execute_query runs queries, and inspect_table retrieves metadata. The descriptions reinforce these distinct functions, making misselection unlikely.

Naming Consistency5/5

All tools follow a consistent verb_noun pattern (cancel_query, execute_query, inspect_table) with snake_case throughout. This predictable naming makes the tool set easy to understand and navigate.

Tool Count3/5

With only 3 tools, the set feels thin for a database query server. While the tools cover core operations, additional utilities like listing tables or checking query status would enhance the surface. The count is borderline but functional.

Completeness3/5

The tools cover query execution, cancellation, and table inspection, but there are notable gaps. Missing operations include listing catalogs/schemas/tables, checking query status, or managing sessions, which could limit agent workflows. The surface is functional but incomplete.

Maintenance

ActivityNo data
ResponsivenessSyncing

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Related MCP Servers

Appeared in Searches

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/stinkgen/trino_mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server