AIエージェント、MCPクライアント（ Cursor 、 Claude 、 Windsurf 、 VS Codeなど）、その他のAIアシスタントをKeboolaに接続します。データ、変換、SQLクエリ、ジョブトリガーを公開できます。グルーコードは不要です。エージェントが必要な時に必要な場所で、適切なデータを提供します。
Keboola MCP Serverは、Keboolaプロジェクトと最新のAIツールをつなぐオープンソースのブリッジです。ストレージアクセス、SQL変換、ジョブトリガーといったKeboolaの機能を、Claude、Cursor、CrewAI、LangChain、Amazon Qなどから呼び出し可能なツールに変換します。
Related MCP server: Google BigQuery MCP Server by CData
ストレージ: テーブルを直接クエリし、テーブルまたはバケットの説明を管理します
コンポーネント: 抽出機能、ライター、データ アプリ、変換構成の作成、一覧表示、検査
SQL :自然言語でSQL変換を作成する
ジョブ: コンポーネントと変換を実行し、ジョブ実行の詳細を取得します。
メタデータ:自然言語を使用してプロジェクトドキュメントとオブジェクトのメタデータを検索、読み取り、更新します。
以下のものを用意してください:
[ ] Python 3.10以上がインストールされている
[ ] 管理者権限でKeboolaプロジェクトにアクセスする
[ ] ご希望のMCPクライアント（Claude、Cursorなど）
注： uvがインストールされていることを確認してください。MCPクライアントはuvを使用して、Keboola MCPサーバーを自動的にダウンロードして実行します。uvのインストール：
macOS/Linux :
#if homebrew is not installed on your machine use:
# /bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"
# Install using Homebrew
brew install uvウィンドウズ:
# Using the installer script
powershell -ExecutionPolicy ByPass -c "irm https://astral.sh/uv/install.ps1 | iex"
# Or using pip
pip install uv
# Or using winget
winget install --id=astral-sh.uv -eその他のインストール オプションについては、公式の uv ドキュメントを参照してください。
MCP サーバーをセットアップする前に、次の 3 つの重要な情報が必要です。
これは Keboola の認証トークンです:
Storage API トークンの作成および管理方法については、 Keboola の公式ドキュメントを参照してください。
注: MCP サーバーのアクセスを制限する場合はカスタム ストレージ トークンを使用し、MCP がプロジェクト内のすべてのものにアクセスできるようにする場合はマスター トークンを使用します。
これは Keboola 内のワークスペースを識別するもので、SQL クエリに必要です。
KBC_WORKSPACE_SCHEMA を取得するには、このKeboola ガイドに従ってください。
注: ワークスペースを作成するときに、すべてのプロジェクトデータへの読み取り専用アクセスを許可するオプションをオンにします。
Keboola APIのURLは、デプロイ先のリージョンによって異なります。Keboolaプロジェクトにログインした際にブラウザに表示されるURLを確認することで、リージョンを確認できます。
地域 | API URL |
AWS 北米 |
|
AWSヨーロッパ |
|
Google Cloud EU |
|
Google Cloud 米国 |
|
アズールEU |
|
Keboola プロジェクトで BigQuery バックエンドを使用する場合は、 KBC_STORAGE_TOKENとKBC_WORKSPACE_SCHEMAに加えて、 GOOGLE_APPLICATION_CREDENTIALS環境変数を設定する必要があります。
Keboola BigQueryワークスペースに移動し、資格情報を表示します（[接続]ボタンをクリックします）。
認証情報ファイルをローカルディスクにダウンロードします。これはプレーンなJSONファイルです。
ダウンロードしたJSON認証情報ファイルのフルパスをGOOGLE_APPLICATION_CREDENTIALS環境変数に設定します。
これにより、MCP サーバー インスタンスに Google Cloud の BigQuery ワークスペースへのアクセス許可が付与されます。注: KBC_WORKSPACE_SCHEMA は BigQuery ワークスペースではデータセット名と呼ばれます。接続をクリックしてデータセット名をコピーするだけです。
Keboola MCP サーバーを使用するには、ニーズに応じて 4 つの方法があります。
このモードでは、Claude または Cursor が自動的に MCP サーバーを起動します。ターミナルでコマンドを実行する必要はありません。
MCPクライアント（Claude/Cursor）を適切な設定で構成します
クライアントは必要に応じてMCPサーバーを自動的に起動します。
Claude（画面の左上隅）に移動 -> 設定 → 開発者 → 構成の編集（claude_desktop_config.json が表示されない場合は作成してください）
次の構成を追加します。
変更を有効にするには、Claude デスクトップを再起動してください。
{
"mcpServers": {
"keboola": {
"command": "uvx",
"args": [
"keboola_mcp_server",
"--api-url", "https://connection.YOUR_REGION.keboola.com"
],
"env": {
"KBC_STORAGE_TOKEN": "your_keboola_storage_token",
"KBC_WORKSPACE_SCHEMA": "your_workspace_schema"
}
}
}
}注: BigQuery ユーザーの場合は、次の行を "env": {}: "GOOGLE_APPLICATION_CREDENTIALS": "/full/path/to/credentials.json" に追加してください。
設定ファイルの場所:
macOS : ~/Library/Application Support/Claude/claude_desktop_config.json
Windows : %APPDATA%\Claude\claude_desktop_config.json
設定→MCPへ移動
「+新しいグローバルMCPサーバーを追加」をクリックします
次の設定を構成します。
{
"mcpServers": {
"keboola": {
"command": "uvx",
"args": [
"keboola_mcp_server",
"--api-url", "https://connection.YOUR_REGION.keboola.com"
],
"env": {
"KBC_STORAGE_TOKEN": "your_keboola_storage_token",
"KBC_WORKSPACE_SCHEMA": "your_workspace_schema"
}
}
}
}注: BigQuery ユーザーの場合は、次の行を "env": {}: "GOOGLE_APPLICATION_CREDENTIALS": "/full/path/to/credentials.json" に追加してください。
Cursor AI を使用して Windows Subsystem for Linux から MCP サーバーを実行する場合は、次の構成を使用します。
{
"mcpServers": {
"keboola": {
"command": "wsl.exe",
"args": [
"bash",
"-c",
"'source /wsl_path/to/keboola-mcp-server/.env",
"&&",
"/wsl_path/to/keboola-mcp-server/.venv/bin/python -m keboola_mcp_server.cli --transport stdio'"
]
}
}
}/wsl_path/to/keboola-mcp-server/.envファイルには環境変数が含まれています。
export KBC_STORAGE_TOKEN="your_keboola_storage_token"
export KBC_WORKSPACE_SCHEMA="your_workspace_schema"MCP サーバー コード自体に取り組んでいる開発者向け:
リポジトリをクローンしてローカル環境をセットアップする
ローカル Python パスを使用するように Claude/Cursor を設定します。
{
"mcpServers": {
"keboola": {
"command": "/absolute/path/to/.venv/bin/python",
"args": [
"-m", "keboola_mcp_server.cli",
"--transport", "stdio",
"--api-url", "https://connection.YOUR_REGION.keboola.com"
],
"env": {
"KBC_STORAGE_TOKEN": "your_keboola_storage_token",
"KBC_WORKSPACE_SCHEMA": "your_workspace_schema",
}
}
}
}注: BigQuery ユーザーの場合は、次の行を "env": {}: "GOOGLE_APPLICATION_CREDENTIALS": "/full/path/to/credentials.json" に追加してください。
テストやデバッグのために、ターミナルでサーバーを手動で実行できます。
# Set environment variables
export KBC_STORAGE_TOKEN=your_keboola_storage_token
export KBC_WORKSPACE_SCHEMA=your_workspace_schema
# For BigQuery users
# export GOOGLE_APPLICATION_CREDENTIALS=/full/path/to/credentials.json
# Run with uvx (no installation needed)
uvx keboola_mcp_server --api-url https://connection.YOUR_REGION.keboola.com
# OR, if developing locally
python -m keboola_mcp_server.cli --api-url https://connection.YOUR_REGION.keboola.com注：このモードは主にデバッグまたはテスト用です。ClaudeまたはCursorでの通常の使用では、サーバーを手動で実行する必要はありません。
docker pull keboola/mcp-server:latest
# For Snowflake users
docker run -it \
-e KBC_STORAGE_TOKEN="YOUR_KEBOOLA_STORAGE_TOKEN" \
-e KBC_WORKSPACE_SCHEMA="YOUR_WORKSPACE_SCHEMA" \
keboola/mcp-server:latest \
--api-url https://connection.YOUR_REGION.keboola.com
# For BigQuery users (add credentials volume mount)
# docker run -it \
# -e KBC_STORAGE_TOKEN="YOUR_KEBOOLA_STORAGE_TOKEN" \
# -e KBC_WORKSPACE_SCHEMA="YOUR_WORKSPACE_SCHEMA" \
# -e GOOGLE_APPLICATION_CREDENTIALS="/creds/credentials.json" \
# -v /local/path/to/credentials.json:/creds/credentials.json \
# keboola/mcp-server:latest \
# --api-url https://connection.YOUR_REGION.keboola.comシナリオ | 手動で実行する必要がありますか? | この設定を使用する |
クロード/カーソルの使用 | いいえ | アプリ設定でMCPを構成する |
MCPをローカルで開発する | いいえ（クロードが始める） | 設定をPythonパスにポイントする |
CLIを手動でテストする | はい | ターミナルを使用して実行する |
Dockerの使用 | はい | Dockerコンテナを実行する |
MCP クライアント (Claude/Cursor) が構成され実行されると、Keboola データのクエリを開始できます。
すべてが機能していることを確認するために、簡単なクエリから始めることができます。
What buckets and tables are in my Keboola project?データ探索:
「どのテーブルに顧客情報が含まれていますか？」
「クエリを実行して、収益上位10社の顧客を検索する」
データ分析:
「前四半期の地域別の売上データを分析する」
「顧客年齢と購入頻度の相関関係を見つける」
データ パイプライン:
「顧客テーブルと注文テーブルを結合する SQL 変換を作成する」
「Salesforce コンポーネントのデータ抽出ジョブを開始する」
MCPクライアント | サポートステータス | 接続方法 |
クロード（デスクトップとウェブ） | ✅ サポート、テスト済み | 標準入出力 |
カーソル | ✅ サポート、テスト済み | 標準入出力 |
ウィンドサーフィン、ゼッド、レプリット | ✅ サポートされています | 標準入出力 |
Codeium、Sourcegraph | ✅ サポートされています | HTTP+SSE |
カスタム MCP クライアント | ✅ サポートされています | HTTP+SSEまたはstdio |
注： Keboola MCPは1.0より前のバージョンであるため、互換性を破る変更が発生する可能性があります。AIエージェントは新しいツールに自動的に適応します。
カテゴリ | 道具 | 説明 |
ストレージ |
| Keboola プロジェクト内のすべてのストレージ バケットを一覧表示します |
| 特定のバケットに関する詳細情報を取得します | |
| 特定のバケット内のすべてのテーブルを返します | |
| 特定のテーブルの詳細情報を提供します | |
| バケットの説明を更新します | |
| テーブル内の特定の列の説明を更新します。 | |
| テーブルの説明を更新します | |
SQL |
| データに対してカスタムSQLクエリを実行します |
| ワークスペースが Snowflake または BigQuery SQL 方言を使用しているかどうかを識別します | |
成分 |
| カスタムパラメータを使用してコンポーネント構成を作成します |
| カスタムパラメータを使用してコンポーネント構成行を作成します | |
| カスタムクエリを使用してSQL変換を作成します | |
| 指定されたクエリに一致するコンポーネントIDのリストを返します | |
| IDを指定して特定のコンポーネントに関する情報を取得します | |
| 特定のコンポーネント/変換構成に関する情報を取得します | |
| 特定のコンポーネントのサンプル構成例を取得します | |
| プロジェクトに存在するコンポーネントの構成を取得します | |
| プロジェクト内の変換構成を取得します | |
| 特定のコンポーネント構成を更新します | |
| 特定のコンポーネント構成行を更新します | |
| 既存のSQL変換構成を更新します | |
仕事 |
| ステータス、コンポーネント、または構成別にジョブを一覧表示およびフィルタリングします |
| 特定のジョブに関する包括的な詳細を返します | |
| コンポーネントまたは変換ジョブの実行をトリガーします | |
ドキュメント |
| 自然言語クエリに基づいてKeboolaドキュメントを検索します |
問題 | 解決 |
認証エラー |
|
ワークスペースの問題 |
|
接続タイムアウト | ネットワーク接続を確認する |
基本設定:
uv sync --extra dev基本的な設定では、 uv run toxを使用してテストを実行し、コード スタイルをチェックできます。
推奨設定:
uv sync --extra dev --extra tests --extra integtests --extra codestyle推奨設定では、テストおよびコード スタイル チェック用のパッケージがインストールされ、開発中に VsCode や Cursor などの IDE でコードをチェックしたりテストを実行したりできるようになります。
ローカルで統合テストを実行するには、 uv run tox -e integtestsを使用します。注: 以下の環境変数を設定する必要があります。
INTEGTEST_STORAGE_API_URL
INTEGTEST_STORAGE_TOKEN
INTEGTEST_WORKSPACE_SCHEMA
これらの値を取得するには、統合テスト専用の Keboola プロジェクトが必要です。
uv.lockの更新依存関係を追加または削除した場合は、 uv.lockファイルを更新してください。また、リリースを作成する際に、依存関係の新しいバージョンでロックを更新することも検討してください（ uv lock --upgrade ）。
⭐ ヘルプを取得したり、バグを報告したり、機能をリクエストしたりする主な方法は、 GitHub で問題を開くことです。⭐
開発チームは問題を積極的に監視しており、可能な限り迅速に対応いたします。Keboolaに関する一般的な情報については、以下のリソースをご利用ください。
問題トラッカー← MCP サーバーの主な連絡方法
Get detailed information about a specific bucket.
| Name | Required | Description | Default |
|---|---|---|---|
| bucket_id | Yes | Unique ID of the bucket. |
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 but doesn't cover critical aspects like whether this is a read-only operation, potential rate limits, authentication needs, error handling, or what 'detailed information' entails. This leaves significant gaps for a tool that likely interacts with storage systems.
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 a single, efficient sentence that directly states the tool's purpose without unnecessary words. It's front-loaded and wastes no space, making it easy for an agent 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 lack of annotations and output schema, the description is incomplete. It doesn't explain what 'detailed information' includes, potential return formats, or behavioral traits like safety and performance. For a tool that likely provides metadata, more context is needed to guide effective 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 input schema has 100% description coverage, with the single parameter 'bucket_id' clearly documented. The description adds no additional meaning beyond the schema, such as format examples or constraints, but since the schema is comprehensive, a baseline score of 3 is appropriate.
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 verb 'Get' and the resource 'detailed information about a specific bucket', making the purpose understandable. However, it doesn't differentiate from sibling tools like 'list_bucket_info' or 'get_table_metadata', which likely serve related but distinct purposes, preventing a perfect score.
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. With siblings such as 'list_bucket_info' and 'get_table_metadata' available, there's no indication of context, prerequisites, or exclusions, leaving the agent to guess based on names alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get detailed information about a specific table including its DB identifier and column information.
| Name | Required | Description | Default |
|---|---|---|---|
| table_id | Yes | Unique ID of the table. |
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 tool retrieves 'detailed information' but doesn't specify behavioral traits like whether it's read-only, requires specific permissions, has rate limits, or what happens if the table doesn't exist. This is a significant gap for a tool with no annotation coverage.
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 a single, efficient sentence that front-loads the core purpose. It avoids unnecessary words, though it could be slightly more structured by explicitly separating the tool's action from the information retrieved.
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 moderate complexity (retrieving metadata for a specific table), no annotations, no output schema, and 100% schema coverage, the description is minimally adequate. It covers the basic purpose but lacks details on usage context, behavioral traits, and output format, leaving gaps in completeness.
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 schema description coverage is 100%, with the single parameter 'table_id' documented as 'Unique ID of the table.' The description adds no additional meaning beyond what the schema provides, such as format examples or constraints. With high schema coverage, the baseline score of 3 is appropriate.
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 detailed information') and resource ('about a specific table'), including what information is retrieved ('DB identifier and column information'). However, it doesn't explicitly differentiate from sibling tools like 'list_bucket_tables' or 'query_table', which prevents a perfect score.
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, when not to use it, or how it differs from sibling tools such as 'list_bucket_tables' (which might list tables) or 'query_table' (which might query table data).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List information about all buckets in the project.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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 action ('List information') but doesn't describe what 'information' includes, whether it's paginated, requires specific permissions, or has rate limits. This is a significant gap for a tool with zero annotation coverage.
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 a single, efficient sentence that directly states the tool's purpose without any fluff or redundancy. It's appropriately sized and front-loaded, making it easy for an agent 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 lack of annotations and output schema, the description is incomplete. It doesn't specify what 'information' is returned, how results are formatted, or any behavioral traits like error handling. For a tool with no structured data support, this leaves too many unknowns for reliable 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 tool has 0 parameters, and schema description coverage is 100%, so there's no need for parameter details in the description. The baseline for 0 parameters is 4, as the description doesn't need to compensate for any schema gaps.
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 verb ('List') and resource ('information about all buckets in the project'), making the purpose immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'get_bucket_metadata' or 'list_bucket_tables', which might offer overlapping functionality.
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 like 'get_bucket_metadata' or 'list_bucket_tables'. There's no mention of prerequisites, context, or exclusions, leaving the agent to infer usage based on tool names alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all tables in a specific bucket with their basic information.
| Name | Required | Description | Default |
|---|---|---|---|
| bucket_id | Yes | Unique ID of the bucket. |
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 this is a list operation but doesn't mention whether it's paginated, rate-limited, requires specific permissions, or what format the 'basic information' returns. For a tool with zero annotation coverage, this leaves significant behavioral gaps.
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 a single, efficient sentence that gets straight to the point with no wasted words. It's appropriately sized for a simple list operation, though it could be slightly more front-loaded with key behavioral details given the lack of annotations.
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 lack of annotations and output schema, the description is incomplete. It doesn't explain what 'basic information' includes, how results are structured, or any behavioral constraints. For a tool that presumably returns multiple items, this leaves the agent with insufficient context for effective 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?
Schema description coverage is 100%, so the input schema already documents the single 'bucket_id' parameter thoroughly. The description adds no additional parameter semantics beyond what's in the schema, meeting the baseline expectation when schema does the heavy lifting.
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 ('List all tables') and target resource ('in a specific bucket'), providing a specific verb+resource combination. However, it doesn't distinguish this tool from sibling tools like 'list_bucket_info' or 'get_table_metadata', which might offer similar or overlapping functionality.
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 like 'list_bucket_info' or 'query_table'. It mentions 'basic information' but doesn't clarify what that includes or exclude compared to other tools, leaving the agent to guess about appropriate usage contexts.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all configurations for a specific component.
| Name | Required | Description | Default |
|---|---|---|---|
| component_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. While 'List all configurations' implies a read operation, it doesn't address important behavioral aspects like pagination, rate limits, authentication requirements, error conditions, or what format the configurations are returned in. The description is minimal and lacks operational context.
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 extremely concise - a single sentence that gets straight to the point with zero wasted words. It's appropriately sized for a simple listing tool and front-loads the essential information.
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?
For a tool with no annotations, no output schema, and 0% schema description coverage, the description is inadequate. It doesn't explain what 'configurations' means in this context, what format they're returned in, whether there are limitations on what can be listed, or provide any operational context. The minimal description leaves too many questions unanswered.
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?
With 0% schema description coverage and 1 undocumented parameter, the description provides no additional semantic information about the 'component_id' parameter. It doesn't explain what constitutes a valid component ID, where to find component IDs, or provide any examples or constraints beyond what's minimally implied by the parameter name.
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 ('List all configurations') and the target resource ('for a specific component'), providing a specific verb+resource combination. However, it doesn't differentiate this tool from its sibling 'list_components', which appears to list components rather than their configurations.
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. There's no mention of prerequisites, when-not-to-use scenarios, or how this differs from sibling tools like 'list_components' or other metadata tools on the server.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all available components and their configurations.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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 action ('List all available components and their configurations') but doesn't reveal critical traits like whether this is a read-only operation, potential rate limits, authentication needs, or what the output format entails. This leaves significant gaps for a tool with no structured safety hints.
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 a single, efficient sentence that front-loads the core action ('List all available components and their configurations') with zero waste. Every word serves a purpose, making it highly concise and well-structured for quick comprehension.
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 simplicity (0 parameters, no output schema, no annotations), the description is adequate as a basic overview. However, it lacks details on output format, behavioral constraints, and differentiation from siblings, which could be important for an agent to use it correctly in context with other tools.
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 tool has 0 parameters, and the schema description coverage is 100%, so there are no parameters to document. The description appropriately doesn't add unnecessary param details, earning a high baseline score for not overcomplicating a parameterless tool.
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 verb ('List') and resource ('components and their configurations'), making the purpose immediately understandable. However, it doesn't distinguish this tool from its sibling 'list_component_configs', which appears to serve a similar function, preventing a perfect score.
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 like 'list_component_configs' or other sibling tools. It lacks context about prerequisites, timing, or any explicit when/when-not instructions, leaving the agent with minimal usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Executes an SQL SELECT query to get the data from the underlying snowflake database.
* When constructing the SQL SELECT query make sure to use the fully qualified table names
that include the database name, schema name and the table name.
* The fully qualified table name can be found in the table information, use a tool to get the information
about tables. The fully qualified table name can be found in the response for that tool.
* Snowflake is case-sensitive so always wrap the column names in double quotes.
Examples:
* SQL queries must include the fully qualified table names including the database name, e.g.:
SELECT * FROM "db_name"."db_schema_name"."table_name";
| Name | Required | Description | Default |
|---|---|---|---|
| sql_query | Yes | SQL SELECT query to run. |
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 does well by specifying that this is for SQL SELECT queries only (implying read-only operations), mentioning Snowflake's case-sensitivity requirements, and providing implementation guidance about fully qualified table names. However, it doesn't address potential limitations like query timeouts, result size limits, or authentication requirements.
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 efficiently organized. It starts with the core purpose, then provides bulleted implementation guidance, and concludes with concrete examples. Every sentence serves a clear purpose without redundancy, making it easy for an AI agent to parse and apply the information.
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?
For a tool with no annotations and no output schema, the description provides reasonable coverage of the execution behavior and requirements. However, it doesn't describe what the output looks like (result format, error responses), which is a significant gap given the absence of output schema. The description adequately covers the input requirements but leaves the output behavior unspecified.
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?
With 100% schema description coverage for the single parameter 'sql_query', the schema already documents this parameter adequately. The description adds some value by providing examples and formatting requirements (double quotes, fully qualified names), but doesn't significantly enhance the parameter understanding beyond what the schema provides. This meets the baseline expectation for high schema coverage.
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 'executes an SQL SELECT query to get the data from the underlying snowflake database', which specifies the verb (executes), resource (SQL SELECT query), and target system (Snowflake database). However, it doesn't explicitly differentiate from sibling tools like get_table_metadata or list_bucket_tables, which appear to be metadata-focused rather than data retrieval tools.
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 clear context about when to use this tool - for executing SQL SELECT queries against Snowflake databases. It mentions prerequisites like using fully qualified table names and referencing table information from other tools, but doesn't explicitly state when NOT to use it or name specific alternatives among the sibling tools.
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.0get_bucket_metadataget_table_metadatalist_bucket_infolist_bucket_tableslist_component_configslist_componentsquery_tableScored across 7 tools
Each tool has a clearly distinct purpose with no overlap: get_bucket_metadata vs list_bucket_info (detail vs list), get_table_metadata vs query_table (metadata vs data retrieval), and list_bucket_tables vs list_components (bucket-specific vs component-focused). The descriptions reinforce these distinctions, making misselection unlikely.
All tools follow a consistent verb_noun pattern with snake_case: get_*, list_*, and query_* are used predictably throughout. The naming is uniform and readable, with no deviations in style or convention.
With 7 tools, the count is well-scoped for a Keboola Explorer server focused on metadata retrieval and data querying. Each tool earns its place, covering buckets, tables, components, and queries without being overwhelming or too sparse.
The tool set provides strong coverage for exploration and querying in Keboola, with metadata listing and retrieval for buckets, tables, and components, plus data querying. A minor gap exists in write operations (e.g., creating or modifying resources), but agents can effectively navigate and query the environment with the available tools.
MCP server unifying ERPs, CRMs, APIs and knowledge base for Claude, ChatGPT and Gemini.
Hosted Amazon Seller Central and Amazon Ads MCP server for Claude, ChatGPT, Cursor, and agents.
Hosted MCP server connecting claude.ai, ChatGPT and other AI apps to your own computer
An MCP server that provides read access to your cloud storage providers, bank accounts and more.
