Conecte sus agentes de IA, clientes MCP ( Cursor , Claude , Windsurf , VS Code , etc.) y otros asistentes de IA a Keboola. Exponga datos, transformaciones, consultas SQL y activadores de trabajos sin necesidad de código de enlace. Entregue los datos correctos a los agentes cuando y donde los necesiten.
Keboola MCP Server es un puente de código abierto entre su proyecto Keboola y las herramientas modernas de IA. Convierte las funciones de Keboola (como el acceso al almacenamiento, las transformaciones SQL y los activadores de trabajos) en herramientas invocables para Claude, Cursor, CrewAI, LangChain, Amazon Q y más.
Related MCP server: Google BigQuery MCP Server by CData
Almacenamiento : consulte tablas directamente y administre descripciones de tablas o depósitos
Componentes : crear, enumerar e inspeccionar extractores, escritores, aplicaciones de datos y configuraciones de transformación
SQL : Crea transformaciones SQL con lenguaje natural
Trabajos : ejecutar componentes y transformaciones, y recuperar detalles de ejecución de trabajos
Metadatos : busque, lea y actualice la documentación del proyecto y los metadatos de los objetos utilizando lenguaje natural
Asegúrese de tener:
[ ] Python 3.10+ instalado
[ ] Acceso a un proyecto de Keboola con derechos de administrador
[ ] Su cliente MCP preferido (Claude, Cursor, etc.)
Nota : Asegúrese de tener instalado uv . El cliente MCP lo usará para descargar y ejecutar automáticamente el servidor MCP de Keboola. Instalación de 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 uvVentanas :
# 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 -ePara obtener más opciones de instalación, consulte la documentación oficial de uv .
Antes de configurar el servidor MCP, necesita tres datos clave:
Este es su token de autenticación para Keboola:
Para obtener instrucciones sobre cómo crear y administrar tokens de API de almacenamiento, consulte la documentación oficial de Keboola .
Nota : Si desea que el servidor MCP tenga acceso limitado, utilice un token de almacenamiento personalizado; si desea que MCP acceda a todo en su proyecto, utilice el token maestro.
Esto identifica su espacio de trabajo en Keboola y es necesario para las consultas SQL:
Siga esta guía de Keboola para obtener su KBC_WORKSPACE_SCHEMA.
Nota : Marque la opción Otorgar acceso de solo lectura a todos los datos del proyecto al crear el espacio de trabajo
La URL de la API de Keboola depende de la región de implementación. Puede determinar su región consultando la URL en su navegador al iniciar sesión en su proyecto de Keboola:
Región | URL de la API |
AWS Norteamérica |
|
AWS Europa |
|
Google Cloud UE |
|
Google Cloud EE. UU. |
|
Azure UE |
|
Si su proyecto Keboola usa el backend de BigQuery, deberá configurar la variable de entorno GOOGLE_APPLICATION_CREDENTIALS además de KBC_STORAGE_TOKEN y KBC_WORKSPACE_SCHEMA :
Vaya a su espacio de trabajo de Keboola BigQuery y muestre sus credenciales (haga clic en el botón Conectar)
Descargue el archivo de credenciales a su disco local. Es un archivo JSON simple.
Establezca la ruta completa del archivo de credenciales JSON descargado en la variable de entorno GOOGLE_APPLICATION_CREDENTIALS
Esto le dará a su instancia del servidor MCP permisos para acceder a su espacio de trabajo de BigQuery en Google Cloud. Nota : KBC_WORKSPACE_SCHEMA se denomina Nombre del conjunto de datos en el espacio de trabajo de BigQuery, simplemente haga clic en Conectar y copie el Nombre del conjunto de datos.
Hay cuatro formas de utilizar el servidor Keboola MCP, según sus necesidades:
En este modo, Claude o Cursor inician automáticamente el servidor MCP. No es necesario ejecutar ningún comando en la terminal .
Configure su cliente MCP (Claude/Cursor) con la configuración adecuada
El cliente iniciará automáticamente el servidor MCP cuando sea necesario
Vaya a Claude (esquina superior izquierda de su pantalla) -> Configuración → Desarrollador → Editar configuración (si no ve el archivo claude_desktop_config.json, créelo)
Agregue la siguiente configuración:
Reinicie el escritorio de Claude para que los cambios surtan efecto.
{
"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"
}
}
}
}Nota : Para los usuarios de BigQuery, agregue la siguiente línea en "env": {}: "GOOGLE_APPLICATION_CREDENTIALS": "/full/path/to/credentials.json"
Ubicaciones de los archivos de configuración:
macOS : ~/Library/Application Support/Claude/claude_desktop_config.json
Ventanas : %APPDATA%\Claude\claude_desktop_config.json
Vaya a Configuración → MCP
Haga clic en "+ Agregar nuevo servidor MCP global".
Configure con estos ajustes:
{
"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"
}
}
}
}Nota : Para los usuarios de BigQuery, agregue la siguiente línea en "env": {}: "GOOGLE_APPLICATION_CREDENTIALS": "/full/path/to/credentials.json"
Al ejecutar el servidor MCP desde el Subsistema de Windows para Linux con Cursor AI, utilice esta configuración:
{
"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'"
]
}
}
}Donde el archivo /wsl_path/to/keboola-mcp-server/.env contiene variables de entorno:
export KBC_STORAGE_TOKEN="your_keboola_storage_token"
export KBC_WORKSPACE_SCHEMA="your_workspace_schema"Para los desarrolladores que trabajan en el código del servidor MCP:
Clonar el repositorio y configurar un entorno local
Configure Claude/Cursor para utilizar su ruta local de 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",
}
}
}
}Nota : Para los usuarios de BigQuery, agregue la siguiente línea en "env": {}: "GOOGLE_APPLICATION_CREDENTIALS": "/full/path/to/credentials.json"
Puede ejecutar el servidor manualmente en una terminal para realizar pruebas o depuraciones:
# 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.comNota : Este modo se utiliza principalmente para depuración o pruebas. Para un uso normal con Claude o Cursor, no es necesario ejecutar el servidor manualmente.
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.comGuión | ¿Necesita ejecutarlo manualmente? | Utilice esta configuración |
Usando Claude/Cursor | No | Configurar MCP en la configuración de la aplicación |
Desarrollo de MCP localmente | No (Claude empieza) | Apuntar la configuración a la ruta de Python |
Probar la CLI manualmente | Sí | Utilice la terminal para ejecutar |
Usando Docker | Sí | Ejecutar contenedor docker |
Una vez que su cliente MCP (Claude/Cursor) esté configurado y en funcionamiento, puede comenzar a consultar sus datos de Keboola:
Puedes comenzar con una consulta sencilla para confirmar que todo funciona:
What buckets and tables are in my Keboola project?Exploración de datos:
"¿Qué tablas contienen información del cliente?"
Ejecute una consulta para encontrar los 10 clientes principales por ingresos.
Análisis de datos:
Analizar mis datos de ventas por región del último trimestre.
"Encuentre correlaciones entre la edad del cliente y la frecuencia de compra"
Tuberías de datos:
"Crear una transformación SQL que una las tablas de clientes y pedidos"
"Iniciar el trabajo de extracción de datos para mi componente de Salesforce"
Cliente MCP | Estado de soporte | Método de conexión |
Claude (Escritorio y Web) | ✅ soportado, probado | estudio |
Cursor | ✅ soportado, probado | estudio |
Windsurf, Zed, Replit | ✅ Compatible | estudio |
Codeium, Sourcegraph | ✅ Compatible | HTTP+SSE |
Clientes MCP personalizados | ✅ Compatible | HTTP+SSE o stdio |
Nota: Keboola MCP es una versión anterior a la 1.0, por lo que podrían producirse cambios importantes. Sus agentes de IA se adaptarán automáticamente a las nuevas herramientas.
Categoría | Herramienta | Descripción |
Almacenamiento |
| Enumera todos los depósitos de almacenamiento en su proyecto Keboola |
| Recupera información detallada sobre un depósito específico | |
| Devuelve todas las tablas dentro de un depósito específico | |
| Proporciona información detallada para una tabla específica | |
| Actualiza la descripción de un bucket | |
| Actualiza la descripción de una columna determinada en una tabla. | |
| Actualiza la descripción de una tabla. | |
SQL |
| Ejecuta consultas SQL personalizadas contra sus datos |
| Identifica si su espacio de trabajo utiliza el dialecto SQL de Snowflake o BigQuery | |
Componente |
| Crea una configuración de componente con parámetros personalizados |
| Crea una fila de configuración de componentes con parámetros personalizados | |
| Crea una transformación SQL con consultas personalizadas | |
| Devuelve una lista de ID de componentes que coinciden con la consulta dada | |
| Obtiene información sobre un componente específico dado su ID | |
| Obtiene información sobre una configuración de transformación/componente específica | |
| Recupera ejemplos de configuración de muestra para un componente específico | |
| Recupera configuraciones de componentes presentes en el proyecto. | |
| Recupera configuraciones de transformación en el proyecto. | |
| Actualiza la configuración de un componente específico | |
| Actualiza una fila de configuración de un componente específico | |
| Actualiza una configuración de transformación SQL existente | |
Trabajo |
| Enumera y filtra trabajos por estado, componente o configuración |
| Devuelve detalles completos sobre un trabajo específico | |
| Activa la ejecución de un componente o un trabajo de transformación | |
Documentación |
| Busca documentación de Keboola basándose en consultas en lenguaje natural. |
Asunto | Solución |
Errores de autenticación | Verificar que |
Problemas en el espacio de trabajo | Confirme |
Tiempo de espera de conexión | Comprobar la conectividad de la red |
Configuración básica:
uv sync --extra devCon la configuración básica, puede utilizar uv run tox para ejecutar pruebas y verificar el estilo del código.
Configuración recomendada:
uv sync --extra dev --extra tests --extra integtests --extra codestyleCon la configuración recomendada, se instalarán paquetes para pruebas y verificación del estilo del código, lo que permite que IDE como VsCode o Cursor verifiquen el código o ejecuten pruebas durante el desarrollo.
Para ejecutar pruebas de integración localmente, utilice uv run tox -e integtests . NOTA: Deberá configurar las siguientes variables de entorno:
INTEGTEST_STORAGE_API_URL
INTEGTEST_STORAGE_TOKEN
INTEGTEST_WORKSPACE_SCHEMA
Para obtener estos valores, necesita un proyecto Keboola dedicado a las pruebas de integración.
uv.lockActualice el archivo uv.lock si ha añadido o eliminado dependencias. También considere actualizar el bloqueo con versiones más recientes de las dependencias al crear una versión ( uv lock --upgrade ).
⭐ La forma principal de obtener ayuda, informar errores o solicitar funciones es abriendo un problema en GitHub . ⭐
El equipo de desarrollo monitorea activamente los problemas y responderá lo antes posible. Para obtener información general sobre Keboola, utilice los recursos a continuación.
Rastreador de problemas ← Método de contacto principal para el servidor 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.
