Подключите своих агентов ИИ, клиентов MCP ( Cursor , Claude , Windsurf , VS Code ...) и других помощников ИИ к Keboola. Выставляйте данные, преобразования, запросы SQL и триггеры заданий — не требуется связующий код. Предоставляйте нужные данные агентам тогда и там, где они им нужны.
Keboola MCP Server — это мост с открытым исходным кодом между вашим проектом Keboola и современными инструментами ИИ. Он превращает функции 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 . Клиент MCP будет использовать его для автоматической загрузки и запуска сервера 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.
Примечание : при создании рабочего пространства установите флажок «Предоставить доступ только для чтения ко всем данным проекта».
URL вашего API Keboola зависит от региона развертывания. Вы можете определить свой регион, посмотрев URL в браузере, когда вошли в свой проект Keboola:
Область | URL-адрес API |
AWS Северная Америка |
|
AWS Европа |
|
Google Cloud ЕС |
|
Google Cloud США |
|
Лазурный ЕС |
|
Если ваш проект Keboola использует бэкэнд BigQuery, вам необходимо установить переменную среды GOOGLE_APPLICATION_CREDENTIALS в дополнение к KBC_STORAGE_TOKEN и KBC_WORKSPACE_SCHEMA :
Перейдите в рабочее пространство Keboola BigQuery и отобразите его учетные данные (нажмите кнопку «Подключить»).
Загрузите файл учетных данных на локальный диск. Это простой файл JSON
Задайте полный путь к загруженному файлу учетных данных JSON в переменной среды GOOGLE_APPLICATION_CREDENTIALS
Это предоставит вашему экземпляру сервера MCP разрешения на доступ к вашей рабочей области BigQuery в Google Cloud. Примечание : 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"
При запуске сервера MCP из подсистемы Windows для Linux с Cursor AI используйте следующую конфигурацию:
{
"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Сценарий | Нужно запустить вручную? | Используйте эту настройку |
Использование Клода/Курсора | Нет | Настройте MCP в настройках приложения |
Разработка MCP на местном уровне | Нет (Клод начинает) | Укажите конфигурацию на путь python |
Тестирование CLI вручную | Да | Используйте терминал для запуска |
Использование Докера | Да | Запустить Docker-контейнер |
После настройки и запуска вашего клиента MCP (Claude/Cursor) вы можете начать запрашивать данные Keboola:
Вы можете начать с простого запроса, чтобы убедиться, что все работает:
What buckets and tables are in my Keboola project?Исследование данных:
«Какие таблицы содержат информацию о клиентах?»
«Выполнить запрос, чтобы найти 10 крупнейших клиентов по размеру дохода»
Анализ данных:
«Проанализируйте мои данные о продажах по регионам за последний квартал»
«Найдите корреляции между возрастом клиентов и частотой покупок»
Конвейеры данных:
«Создайте преобразование SQL, которое объединяет таблицы клиентов и заказов»
«Начать задание по извлечению данных для моего компонента Salesforce»
Клиент МСР | Статус поддержки | Метод подключения |
Клод (настольный компьютер и веб) | ✅ поддерживается, протестировано | стдио |
Курсор | ✅ поддерживается, протестировано | стдио |
Виндсерфинг, Зед, Реплит | ✅ Поддерживается | стдио |
Кодеум, Sourcegraph | ✅ Поддерживается | HTTP+SSE |
Пользовательские клиенты MCP | ✅ Поддерживается | HTTP+SSE или stdio |
Примечание: Keboola MCP — это версия pre-1.0, поэтому могут произойти некоторые критические изменения. Ваши агенты ИИ автоматически подстроятся под новые инструменты.
Категория | Инструмент | Описание |
Хранилище |
| Перечисляет все хранилища в вашем проекте Keboola. |
| Извлекает подробную информацию о конкретном контейнере | |
| Возвращает все таблицы в указанном сегменте | |
| Предоставляет подробную информацию для конкретной таблицы | |
| Обновляет описание ведра | |
| Обновляет описание указанного столбца в таблице. | |
| Обновляет описание таблицы | |
SQL |
| Выполняет пользовательские SQL-запросы к вашим данным |
| Определяет, использует ли ваше рабочее пространство диалект Snowflake или BigQuery SQL. | |
Компонент |
| Создает конфигурацию компонента с пользовательскими параметрами |
| Создает строку конфигурации компонента с пользовательскими параметрами | |
| Создает SQL-преобразование с пользовательскими запросами | |
| Возвращает список идентификаторов компонентов, соответствующих заданному запросу. | |
| Получает информацию о конкретном компоненте по его идентификатору | |
| Получает информацию о конкретной конфигурации компонента/преобразования | |
| Извлекает примеры конфигурации для определенного компонента. | |
| Извлекает конфигурации компонентов, присутствующих в проекте. | |
| Извлекает конфигурации преобразований в проекте | |
| Обновляет определенную конфигурацию компонента | |
| Обновляет определенную строку конфигурации компонента | |
| Обновляет существующую конфигурацию преобразования SQL | |
Работа |
| Перечисляет и фильтрует задания по статусу, компоненту или конфигурации |
| Возвращает исчерпывающую информацию о конкретной работе | |
| Запускает компонент или задание по преобразованию для запуска | |
Документация |
| Поиск документации Keboola на основе запросов на естественном языке |
Проблема | Решение |
Ошибки аутентификации | Проверьте действительность |
Проблемы с рабочим пространством | Подтвердите правильность |
Время ожидания соединения истекло | Проверьте сетевое подключение |
Базовая настройка:
uv sync --extra devПри базовой настройке вы можете использовать uv run tox для запуска тестов и проверки стиля кода.
Рекомендуемая настройка:
uv sync --extra dev --extra tests --extra integtests --extra codestyleПри рекомендуемой настройке будут установлены пакеты для тестирования и проверки стиля кода, что позволит таким IDE, как VsCode или Cursor, проверять код или запускать тесты во время разработки.
Для локального запуска интеграционных тестов используйте 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, пожалуйста, используйте ресурсы ниже.
Issue Tracker ← Основной метод связи для MCP Server
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.
