Trino MCP Server
Servidor Trino MCP
Servidor de protocolo de contexto de modelo para Trino, que proporciona modelos de IA con acceso estructurado al motor de consulta SQL distribuido de Trino.
⚠️ VERSIÓN BETA (v0.1.2) ⚠️
Este proyecto se está estabilizando y sus funciones principales funcionan y están probadas. ¡Siéntete libre de bifurcar y contribuir!
Características
✅ ¡Se solucionó el problema de inicialización de la API del contenedor Docker! (inicialización confiable del servidor)
✅ Expone recursos de Trino a través del protocolo MCP
✅ Permite que las herramientas de IA consulten y analicen datos en Trino
✅ Proporciona opciones de transporte (el transporte STDIO funciona de manera confiable; el transporte SSE tiene problemas)
✅ Se corrigió el manejo del catálogo para la correcta ejecución de consultas Trino
✅ Opciones de servidor API de Python independiente y API de contenedor Docker
Related MCP server: Trino MCP Server
Inicio rápido
# 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"}'¿Necesita una versión sin contenedor? Ejecute la API independiente:
# Run the standalone API server on port 8008
python llm_trino_api.pyIntegración de LLM
¿Quieres que un LLM tenga acceso directo para consultar tu instancia de Trino? ¡Hemos creado herramientas sencillas para ello!
Interfaz LLM de línea de comandos
La forma más sencilla de permitir que un LLM consulte a Trino es a través de nuestra herramienta de línea de comandos:
# 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_schemaAPI REST para LLM
Ofrecemos dos opciones de API para la integración con aplicaciones LLM:
1. API de contenedor Docker (Puerto 9097)
El contenedor Docker expone una API REST en el puerto 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. API independiente de Python (puerto 8008)
Para implementaciones más flexibles, ejecute el servidor API independiente:
# Start the API server on port 8008
python llm_trino_api.pyEsto crea puntos finales en:
GET http://localhost:8008/- Información de uso de la APIPOST http://localhost:8008/query- Ejecutar consultas SQL
Luego puede hacer que su LLM realice solicitudes HTTP a este punto final:
# 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"])Este enfoque permite que los LLM se concentren en generar SQL, mientras nuestras herramientas manejan toda la complejidad del protocolo MCP.
Scripts de demostración y validación 🚀
Hemos creado algunos scripts de demostración increíbles que muestran cómo los modelos de IA pueden usar el protocolo MCP para ejecutar consultas complejas en Trino:
1. Generación y carga de datos basura
El script tools/create_bullshit_data.py genera un conjunto de datos de 10 000 empleados con cargos ridículos, salarios inflados y una calificación de "factor de estupidez" (del 1 al 10):
# Generate the bullshit data
python tools/create_bullshit_data.py
# Load the bullshit data into Trino's memory catalog
python load_bullshit_data.py2. Ejecución de consultas complejas a través de MCP
El script test_bullshit_query.py demuestra la interacción MCP de extremo a extremo:
Se conecta al servidor MCP mediante el transporte STDIO
Inicializa el protocolo siguiendo la especificación MCP
Ejecuta una consulta SQL compleja con WHERE, GROUP BY, HAVING, ORDER BY
Procesa y formatea los resultados
# Run a complex query against the bullshit data through MCP
python test_bullshit_query.pyEjemplo de salida que muestra los mejores trabajos de BS con salarios altos:
🏆 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. Pruebas de API
El script test_llm_api.py valida la funcionalidad de la API:
# Test the Docker container API
python test_llm_api.pyEsto realiza una verificación exhaustiva de:
Descubrimiento de puntos finales de API
Disponibilidad de la documentación
Ejecución de consulta válida
Manejo de errores para consultas no válidas
Uso
# Start the server with docker-compose
docker-compose up -dEl servidor estará disponible en:
Trino: http://localhost:9095
Servidor MCP: http://localhost:9096
Servidor API: http://localhost:9097
Conexión del cliente
✅ IMPORTANTE : Los scripts del cliente se ejecutan en tu equipo local (FUERA de Docker) y se conectan a los contenedores Docker. Los scripts gestionan esto automáticamente mediante comandos docker exec. ¡No necesitas estar dentro del contenedor para usar MCP!
Ejecutar pruebas desde su máquina local:
# 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 DockerOpciones de transporte
Este servidor admite dos métodos de transporte, pero actualmente solo STDIO es confiable:
Transporte STDIO (recomendado y funcional)
El transporte STDIO funciona de manera confiable y actualmente es el único método recomendado para pruebas y desarrollo:
# 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 memoryTransporte SSE (NO RECOMENDADO - Presenta problemas críticos)
SSE es el transporte predeterminado en MCP, pero presenta graves problemas con la versión actual de MCP 1.3.0, que provocan fallos del servidor al desconectarse el cliente. No se recomienda su uso hasta que se resuelvan estos problemas :
# 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 --debugProblemas conocidos y soluciones
Corregido: Inicialización de la API del contenedor Docker
SOLUCIONADO : Se solucionó un problema por el cual la API del contenedor Docker devolvía respuestas 503 "Servicio no disponible". El problema se debía a que la función app_lifespan no inicializaba correctamente app_context_global ni la conexión del cliente Trino. La solución garantiza que:
El cliente Trino se conecta explícitamente durante el inicio
La variable global AppContext se inicializa correctamente
Los controles de salud ahora funcionan correctamente
Si encuentra errores 503, verifique que su contenedor se haya reconstruido con el código más reciente:
# Rebuild and restart the container with the fix
docker-compose stop trino-mcp
docker-compose rm -f trino-mcp
docker-compose up -d trino-mcpFallos del transporte SSE de MCP 1.3.0
Hay un problema crítico con el transporte SSE de MCP 1.3.0 que provoca fallos del servidor cuando los clientes se desconectan. Hasta que se integre una versión más reciente de MCP, utilice exclusivamente el transporte STDIO. El error se manifiesta como:
RuntimeError: generator didn't stop after athrow()
anyio.BrokenResourceErrorManejo del catálogo Trino
Se solucionó un problema con la gestión del catálogo en el cliente Trino. La implementación original intentaba usar sentencias USE catalog , lo cual no funcionaba correctamente. La solución establece el catálogo directamente en los parámetros de conexión.
Estructura del proyecto
Este proyecto está organizado de la siguiente manera:
src/- Código fuente principal del servidor Trino MCPexamples/- Ejemplos sencillos que muestran cómo utilizar el servidorscripts/- Scripts útiles de diagnóstico y pruebatools/- Scripts de utilidad para la creación y configuración de datostests/- Pruebas automatizadas
Archivos clave:
llm_trino_api.py: servidor API independiente para la integración de LLMtest_llm_api.py- Script de prueba para el servidor APItest_mcp_stdio.py- Script de prueba principal que utiliza el transporte STDIO (recomendado)test_bullshit_query.py- Ejemplo de consulta compleja con datos falsosload_bullshit_data.py- Script para cargar datos generados en Trinotools/create_bullshit_data.py- Script para generar datos de prueba divertidosrun_tests.sh- Script para ejecutar pruebas automatizadasexamples/simple_mcp_query.py- Ejemplo simple para consultar datos usando MCP
Desarrollo
IMPORTANTE : Todos los scripts se pueden ejecutar desde su máquina local: se comunicarán automáticamente con los contenedores Docker a través de comandos docker exec.
# 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"Pruebas
Para probar que las consultas Trino funcionan correctamente, utilice el script de prueba de transporte STDIO:
# Recommended test method (STDIO transport)
python test_mcp_stdio.pyPara realizar pruebas más complejas con datos falsos:
# Load and query the bullshit data (shows the full power of Trino MCP!)
python load_bullshit_data.py
python test_bullshit_query.pyPara probar el punto final de la API de LLM:
# 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"}'Cómo los LLM pueden usar esto
Los LLM pueden utilizar el servidor Trino MCP para:
Obtener información del esquema de la base de datos :
# Example prompt to LLM: "What schemas are available in the memory catalog?" # LLM can generate code to query: query = "SHOW SCHEMAS FROM memory"Ejecutar consultas analíticas complejas :
# 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 """Realizar análisis de datos y presentar resultados :
# 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"
Ejemplo de análisis real de LLM: trabajos basura por empresa
He aquí un ejemplo real de lo que un LLM podría producir cuando se le pide "Identificar las empresas con la mayor cantidad de empleados en trabajos de mierda y crear un gráfico de sirena":
Paso 1: LLM genera y ejecuta la consulta
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 10Paso 2: LLM obtiene y analiza los resultados
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.0Paso 3: LLM genera una visualización del gráfico de sirena
%%{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;Gráfico de barras alternativo:
%%{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)" : 1Paso 4: LLM proporciona información clave
El LLM puede analizar los datos y proporcionar información:
"Unknown Co" tiene la mayor cantidad de empleados en roles de mierda (2), mientras que todos los demás tienen solo uno
La mayoría de las empresas han conseguido una puntuación perfecta de 10,0 en el factor de estupidez.
Las empresas centradas en la tecnología (BitEdge, CyberWare, etc.) parecen crear roles particularmente insignificantes
Los roles de mierda aparecen concentrados en niveles ejecutivos o de puestos especializados
Este ejemplo demuestra cómo un LLM puede:
Generar consultas SQL apropiadas basadas en preguntas en lenguaje natural
Procesar e interpretar los resultados de Trino
Crear representaciones visuales de los datos
Proporcionar información y análisis significativos
Accediendo a la API
El servidor Trino MCP ahora incluye dos opciones de API para acceder a los datos:
1. API de contenedor Docker (Puerto 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. API independiente de Python (puerto 8008)
# Same code as above, but with different port
api_url = "http://localhost:8008/query"Ambas API ofrecen los siguientes puntos finales:
GET /api- Documentación de la API y ejemplos de usoPOST /api/query- Ejecutar consultas SQL contra Trino
Estas API eliminan la necesidad de scripts envolventes y permiten que los LLM consulten a Trino directamente mediante llamadas REST, lo que hace que sea mucho más sencilla la integración con servicios como Claude, GPT y otros sistemas de IA.
Solución de problemas
La API devuelve el error 503: Servicio no disponible
Si la API del contenedor Docker devuelve errores 503:
Asegúrese de haber reconstruido el contenedor con el código más reciente:
docker-compose stop trino-mcp docker-compose rm -f trino-mcp docker-compose up -d trino-mcpVerifique los registros del contenedor para detectar errores:
docker logs trino_mcp_trino-mcp_1Verifique que Trino esté funcionando correctamente:
curl -s http://localhost:9095/v1/info | jq
Conflictos de puertos con API independientes
La API independiente usa el puerto 8008 por defecto para evitar conflictos. Si ve el error "Dirección ya en uso":
Edite
llm_trino_api.pyy cambie el número de puerto en la última línea:uvicorn.run(app, host="127.0.0.1", port=8008)Ejecutar con un puerto personalizado a través de la línea de comando:
python -c "import llm_trino_api; import uvicorn; uvicorn.run(llm_trino_api.app, host='127.0.0.1', port=8009)"
Trabajo futuro
Esta versión ahora está en versión beta con las siguientes mejoras planificadas:
[ ] Integrar con versiones más nuevas de MCP cuando estén disponibles para solucionar problemas de transporte de SSE
[ ] Agregar/Validar soporte para Hive, JDBC y otros conectores
[ ] Agregue una validación de consultas más completa en diferentes tipos y complejidades
[ ] Implementar soporte para más tipos de datos y funciones avanzadas de Trino
[ ] Mejorar los mecanismos de gestión y recuperación de errores
[ ] Agregar controles de permisos y autenticación de usuarios
[ ] Crear ejemplos y documentación más completos
[ ] Desarrollar interfaces de gestión y monitoreo administrativo
[ ] Agregar métricas de rendimiento y sugerencias de optimización de consultas
[ ] Implementar soporte para consultas de larga duración y transmisión de resultados
Desarrollado por Stink Labs, 2025
Available Tools
3 toolscancel_queryC
Cancel a running query.
Args:
query_id: ID of the query to cancel.
Returns:
Dict[str, Any]: Result of the cancellation operation.
| Name | Required | Description | Default |
|---|---|---|---|
| query_id | Yes |
TDQS
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.
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.
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.
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.
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.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| sql | Yes | ||
| catalog | No | ||
| schema | No |
TDQS
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.
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.
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.
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.
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.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| catalog | Yes | ||
| schema | Yes | ||
| table | Yes |
TDQS
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.
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.
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.
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.
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.
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.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
3 tool updates
v1.0.0- Added
cancel_query - Added
execute_query - Added
inspect_table
TDQS
Scored across 3 tools
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.
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.
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.
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
Related MCP Connectors
Query Postgres, MySQL, SQL Server, Oracle, BigQuery, ClickHouse and Redshift from your AI client.
The grounded data layer for any LLM: governed SQL, metrics, lineage and catalog over your data.
Ask data questions in natural language. Get SQL, insights, and charts from your databases.
Connects AI assistants to TrackingTime for querying time entries, projects, tasks, customers, and team data using natural language.
Related MCP Servers
AlicenseAqualityAmaintenanceActs as a bridge between AI assistants and StarRocks databases, allowing for direct SQL execution and database exploration without requiring complex setup or configuration.8193Apache 2.0- AlicenseNot gradedqualityDmaintenanceEnables listing and querying Trino tables via MCP, supporting arbitrary SQL queries against a Trino cluster.MIT
- AlicenseNot gradedqualityAmaintenanceA Model Context Protocol server enabling AI assistants to query and explore data warehouses via Trino, with optional semantic context from metadata catalogs.3Apache 2.0
- FlicenseNot gradedqualityCmaintenanceEnables natural-language queries on Trino big data platforms, generating validated, schema-aware SQL via RAG and local LLM inference, and exposes metadata, query, and profiling tools through MCP.1-