将您的 AI 代理、MCP 客户端（ Cursor 、 Claude 、 Windsurf 、 VS Code等）以及其他 AI 助手连接到 Keboola。公开数据、转换、SQL 查询和作业触发器——无需任何胶水代码。随时随地向代理提供所需的正确数据。
Keboola MCP 服务器是 Keboola 项目与现代 AI 工具之间的开源桥梁。它将 Keboola 的功能（例如存储访问、SQL 转换和作业触发器）转换为可供 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客户端将使用它自动下载并运行 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 服务器之前，您需要三个关键信息：
这是您的 Keboola 身份验证令牌：
有关如何创建和管理存储 API 令牌的说明，请参阅官方 Keboola 文档。
注意：如果您希望 MCP 服务器具有有限的访问权限，请使用自定义存储令牌，如果您希望 MCP 访问项目中的所有内容，请使用主令牌。
这标识了您在 Keboola 中的工作区，并且是 SQL 查询所必需的：
按照此Keboola 指南获取您的 KBC_WORKSPACE_SCHEMA。
注意：创建工作区时，请选中授予对所有项目数据的只读访问权限选项
您的 Keboola API URL 取决于您的部署区域。登录 Keboola 项目后，您可以通过查看浏览器中的 URL 来确定您的区域：
地区 | API URL |
AWS北美 |
|
AWS 欧洲 |
|
Google Cloud 欧盟 |
|
Google Cloud 美国 |
|
Azure 欧盟 |
|
如果您的 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 服务器，具体取决于您的需求：
在此模式下，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 服务器代码本身的开发人员：
克隆存储库并设置本地环境
配置 Claude/Cursor 以使用您的本地 Python 路径：
{
"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设想 | 需要手动运行吗？ | 使用此设置 |
使用 Claude/Cursor | 不 | 在应用程序设置中配置 MCP |
本地开发 MCP | 不（克劳德先开口） | 将配置指向 python 路径 |
手动测试 CLI | 是的 | 使用终端运行 |
使用 Docker | 是的 | 运行docker容器 |
一旦您的 MCP 客户端（Claude/Cursor）配置并运行，您就可以开始查询您的 Keboola 数据：
您可以从一个简单的查询开始来确认一切正常：
What buckets and tables are in my Keboola project?数据探索：
“哪些表包含客户信息？”
“运行查询以查找按收入排名前 10 位的客户”
数据分析：
“按地区分析我上一季度的销售数据”
“找到顾客年龄和购买频率之间的相关性”
数据管道：
“创建一个连接客户表和订单表的 SQL 转换”
“启动我的 Salesforce 组件的数据提取作业”
MCP 客户端 | 支持状态 | 连接方法 |
克劳德（桌面和网络） | ✅ 支持，测试 | 标准输入输出 |
光标 | ✅ 支持，测试 | 标准输入输出 |
风帆冲浪、Zed、Replit | ✅ 支持 | 标准输入输出 |
Codeium、Sourcegraph | ✅ 支持 | HTTP+SSE |
自定义 MCP 客户端 | ✅ 支持 | HTTP+SSE 或 stdio |
注意： Keboola MCP 处于 1.0 之前的版本，因此可能会发生一些重大更改。您的 AI 代理将自动适应新工具。
类别 | 工具 | 描述 |
贮存 |
| 列出 Keboola 项目中的所有存储桶 |
| 检索有关特定存储桶的详细信息 | |
| 返回特定存储桶内的所有表 | |
| 提供特定表的详细信息 | |
| 更新 bucket 的描述 | |
| 更新表中给定列的描述。 | |
| 更新表的描述 | |
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 的常规信息，请使用以下资源。
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.
