Trino のモデル コンテキスト プロトコル サーバー。AI モデルに Trino の分散 SQL クエリ エンジンへの構造化されたアクセスを提供します。
⚠️ベータリリース (v0.1.2) ⚠️
このプロジェクトはコア機能が動作しテスト済みで安定しつつあります。ぜひフォークして貢献してください！
✅ Docker コンテナ API の初期化問題を修正しました。(信頼性の高いサーバーの初期化)
✅ MCPプロトコルを通じてTrinoリソースを公開します
✅ AIツールがTrinoのデータをクエリおよび分析できるようにします
✅ トランスポート オプションを提供します (STDIO トランスポートは確実に動作しますが、SSE トランスポートには問題があります)
✅ Trinoクエリを正しく実行するためのカタログ処理を修正しました
✅ DockerコンテナAPIとスタンドアロンPython APIサーバーオプションの両方
Related MCP server: Trino MCP Server
# 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"}'コンテナ化されていないバージョンが必要ですか？スタンドアロン API を実行してください。
# Run the standalone API server on port 8008
python llm_trino_api.pyLLM に Trino インスタンスへのクエリを直接実行するためのアクセス権を与えたいですか? そのためにシンプルなツールを作成しました。
LLM に Trino をクエリさせる最も簡単な方法は、コマンドライン ツールを使用することです。
# 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_schemaLLM アプリケーションとの統合には、次の 2 つの API オプションがあります。
Docker コンテナはポート 9097 で REST API を公開します。
# 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"}'より柔軟なデプロイメントを実現するには、スタンドアロン API サーバーを実行します。
# Start the API server on port 8008
python llm_trino_api.pyこれにより、次の場所にエンドポイントが作成されます。
GET http://localhost:8008/ - API 使用情報
POST http://localhost:8008/query - SQLクエリを実行する
次に、LLM にこのエンドポイントへの HTTP リクエストを送信させます。
# 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"])このアプローチにより、LLM は SQL の生成に集中でき、当社のツールが MCP プロトコルの複雑な部分をすべて処理できるようになります。
AI モデルが MCP プロトコルを使用して Trino に対して複雑なクエリを実行する方法を示す、優れたデモ スクリプトをいくつか作成しました。
tools/create_bullshit_data.pyスクリプトは、ばかげた役職、水増しされた給与、および「bullshit 係数」評価 (1 ～ 10) を持つ 10,000 人の従業員のデータセットを生成します。
# Generate the bullshit data
python tools/create_bullshit_data.py
# Load the bullshit data into Trino's memory catalog
python load_bullshit_data.pytest_bullshit_query.pyスクリプトは、エンドツーエンドの MCP 相互作用を示します。
STDIOトランスポートを使用してMCPサーバーに接続します
MCP仕様に従ってプロトコルを初期化します
WHERE、GROUP BY、HAVING、ORDER BYを使用した複雑なSQLクエリを実行します。
結果を処理しフォーマットする
# Run a complex query against the bullshit data through MCP
python test_bullshit_query.py高給のトップ BS 職種を示す出力例:
🏆 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!test_llm_api.pyスクリプトは、API 機能を検証します。
# Test the Docker container API
python test_llm_api.pyこれにより、次の包括的なチェックが実行されます。
APIエンドポイントの検出
ドキュメントの入手可能性
有効なクエリ実行
無効なクエリのエラー処理
# Start the server with docker-compose
docker-compose up -dサーバーは次の場所で利用できます:
MCP サーバー: http://localhost:9096
API サーバー: http://localhost:9097
✅重要：クライアントスクリプトはローカルマシン（Dockerの外部）で実行され、Dockerコンテナに接続します。スクリプトはdocker execコマンドを使用してこれを自動的に処理します。MCPを使用するためにコンテナ内に入る必要はありません。
ローカルマシンからテストを実行する:
# 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このサーバーは 2 つの転送方法をサポートしていますが、現在信頼できるのは STDIO のみです。
STDIO トランスポートは確実に動作し、現在テストと開発に推奨される唯一の方法です。
# 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 memorySSEはMCPのデフォルトトランスポートですが、現在のMCPバージョン1.3.0には深刻な問題があり、クライアントの切断時にサーバークラッシュが発生します。これらの問題が解決されるまでは使用を推奨しません。
# 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✅修正済み: Dockerコンテナ内のAPIが503 Service Unavailableレスポンスを返す問題を修正しました。この問題は、 app_lifespan関数がapp_context_globalとTrinoクライアント接続を適切に初期化していなかったことに起因しています。修正により、以下の問題が解決されます。
Trinoクライアントは起動時に明示的に接続します
AppContextグローバル変数が適切に初期化されている
ヘルスチェックが正しく動作するようになりました
503 エラーが発生した場合は、コンテナが最新のコードで再構築されていることを確認してください。
# Rebuild and restart the container with the fix
docker-compose stop trino-mcp
docker-compose rm -f trino-mcp
docker-compose up -d trino-mcpMCP 1.3.0 の SSE トランスポートに重大な問題があり、クライアントの切断時にサーバーがクラッシュします。新しいバージョンの MCP が統合されるまでは、STDIO トランスポートのみを使用してください。エラーは次のように表示されます。
RuntimeError: generator didn't stop after athrow()
anyio.BrokenResourceErrorTrinoクライアントのカタログ処理に関する問題を修正しました。元の実装ではUSE catalogステートメントの使用が試みられていましたが、これは信頼性に欠けていました。修正により、接続パラメータにカタログを直接設定するようになりました。
このプロジェクトは次のように構成されています。
src/ - Trino MCP サーバーのメインソースコード
examples/ - サーバーの使用方法を示す簡単な例
scripts/ - 便利な診断およびテストスクリプト
tools/ - データ作成とセットアップのためのユーティリティスクリプト
tests/ - 自動テスト
主要ファイル:
llm_trino_api.py - LLM 統合用のスタンドアロン API サーバー
test_llm_api.py - APIサーバーのテストスクリプト
test_mcp_stdio.py - STDIO トランスポートを使用したメインテスト スクリプト (推奨)
test_bullshit_query.py - でたらめなデータを使った複雑なクエリの例
load_bullshit_data.py - 生成されたデータを Trino にロードするスクリプト
tools/create_bullshit_data.py - 面白いテストデータを生成するスクリプト
run_tests.sh - 自動テストを実行するスクリプト
examples/simple_mcp_query.py - MCP を使用してデータをクエリする簡単な例
重要: すべてのスクリプトはローカル マシンから実行できます。スクリプトは docker exec コマンドを介して Docker コンテナーと自動的に通信します。
# 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"Trino クエリが正しく動作しているかどうかをテストするには、STDIO トランスポート テスト スクリプトを使用します。
# Recommended test method (STDIO transport)
python test_mcp_stdio.pyでたらめなデータを使ったより複雑なテストの場合:
# Load and query the bullshit data (shows the full power of Trino MCP!)
python load_bullshit_data.py
python test_bullshit_query.pyLLM API エンドポイントをテストするには:
# 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"}'LLM は Trino MCP サーバーを使用して次のことを行うことができます。
データベーススキーマ情報を取得します:
# Example prompt to LLM: "What schemas are available in the memory catalog?"
# LLM can generate code to query:
query = "SHOW SCHEMAS FROM memory"複雑な分析クエリを実行する:
# 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
"""データ分析を実行し、結果を提示する:
# 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"以下は、LLM が「くだらない仕事に就いている従業員が最も多い企業を特定し、マーメイド チャートを作成してください」と要求された場合に作成できる実際の例です。
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 10COMPANY | 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%%{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;代替棒グラフ:
%%{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)" : 1LLM はデータを分析し、洞察を提供できます。
「不明な会社」は、くだらない役職に就いている従業員が最も多く（2人）、他の会社では1人だけである。
ほとんどの企業は完璧な10.0のデタラメ度スコアを達成している
テクノロジーに特化した企業（BitEdge、CyberWareなど）は、特に意味のない役割を作り出しているようだ。
くだらない役割は経営幹部や専門職レベルに集中しているようだ
この例では、LLM が次の機能を実現する方法を示します。
自然言語の質問に基づいて適切なSQLクエリを生成する
Trinoからの結果の処理と解釈
データの視覚的表現を作成する
有意義な洞察と分析を提供する
Trino MCP サーバーには、データにアクセスするための 2 つの API オプションが含まれるようになりました。
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']}")# Same code as above, but with different port
api_url = "http://localhost:8008/query"両方の API は次のエンドポイントを提供します。
GET /api - APIドキュメントと使用例
POST /api/query - Trinoに対してSQLクエリを実行する
これらの API により、ラッパー スクリプトの必要性がなくなり、LLM は REST 呼び出しを使用して Trino を直接クエリできるため、Claude、GPT、その他の AI システムなどのサービスとの統合がはるかに簡単になります。
Docker コンテナ API が 503 エラーを返す場合:
コンテナを最新のコードで再構築したことを確認してください。
docker-compose stop trino-mcp
docker-compose rm -f trino-mcp
docker-compose up -d trino-mcpコンテナのログでエラーを確認します。
docker logs trino_mcp_trino-mcp_1Trino が正常に実行されていることを確認します。
curl -s http://localhost:9095/v1/info | jqスタンドアロンAPIは、競合を避けるため、デフォルトでポート8008を使用します。「アドレスが既に使用されています」というエラーが表示された場合は、以下の手順に従ってください。
llm_trino_api.pyを編集し、最後の行のポート番号を変更します。
uvicorn.run(app, host="127.0.0.1", port=8008) コマンドラインからカスタムポートで実行します。
python -c "import llm_trino_api; import uvicorn; uvicorn.run(llm_trino_api.app, host='127.0.0.1', port=8009)"これは現在ベータ版であり、以下の改善が計画されています:
[ ] SSEトランスポートの問題を修正するために、新しいMCPバージョンが利用可能になったら統合する
[ ] Hive、JDBC、その他のコネクタのサポートを追加/検証
[ ] さまざまなタイプと複雑さにわたる、より包括的なクエリ検証を追加する
[ ] より多くのデータ型と高度なTrino機能のサポートを実装
[ ] エラー処理と回復メカニズムの改善
[ ] ユーザー認証と権限制御を追加する
[ ] より包括的な例とドキュメントを作成する
[ ] 管理者監視および管理インターフェースの開発
[ ] パフォーマンスメトリックとクエリ最適化のヒントを追加する
[ ] 長時間実行クエリと結果ストリーミングのサポートを実装する
Stink Labs開発、2025年
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 |
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 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 |
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.
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 |
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.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v1.0.0cancel_queryexecute_queryinspect_tableScored 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.
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.
