com.keboola/mcp

Updates an existing root component configuration by modifying its parameters, storage mappings, name or description. Not for SQL transformations (`keboola.snowflake-transformation` / `keboola.google-bigquery-transformation`), data apps (`keboola.data-apps`) or flows — use the dedicated tools (see WHEN NOT TO USE). This IS the tool for updating Python (`keboola.python-transformation-v2`), R (`keboola.r-transformation-v2`) and DuckDB (`keboola.duckdb-transformation`) transformations. This tool allows PARTIAL parameter updates - you only need to provide the fields you want to change. All other fields will remain unchanged. Use this tool when modifying existing configurations; for configuration rows, use update_config_row instead. WHEN TO USE: - Modifying configuration parameters (credentials, settings, API keys, etc.) - Updating storage mappings (input/output tables or files) - Changing configuration name or description - Any combination of the above WHEN NOT TO USE: - `keboola.orchestrator` / `keboola.flow` → use `update_flow` - `keboola.data-apps` → use `modify_python_js_data_app` / `modify_streamlit_data_app` / `deploy_data_app` - `keboola.snowflake-transformation` / `keboola.google-bigquery-transformation` → use `update_sql_transformation` PREREQUISITES: - Configuration must already exist (use create_config for new configurations) - You must know both component_id and configuration_id - For parameter updates: Review the component's root_configuration_schema using get_components. - For storage updates: Ensure mappings are valid for the component type IMPORTANT CONSIDERATIONS: - Parameter updates are PARTIAL - only specify fields you want to change - parameter_updates supports granular operations: set keys, replace strings, remove keys, or append to lists - Parameters must conform to the component's root_configuration_schema - Validate schemas before calling: use get_components to retrieve root_configuration_schema - For row-based components, this updates the R…

Updates an existing component configuration row by modifying its parameters, storage mappings, name, or description. This tool allows PARTIAL parameter updates - you only need to provide the fields you want to change. All other fields will remain unchanged. Configuration rows are individual items within a configuration, often representing separate data sources, tables, or endpoints that share the same component type and parent configuration settings. WHEN TO USE: - Modifying row-specific parameters (table sources, filters, credentials, etc.) - Updating storage mappings for a specific row (input/output tables or files) - Changing row name or description - Any combination of the above WHEN NOT TO USE: - `keboola.orchestrator` / `keboola.flow` → use `update_flow` - `keboola.data-apps` → use `modify_python_js_data_app` / `modify_streamlit_data_app` / `deploy_data_app` - `keboola.snowflake-transformation` / `keboola.google-bigquery-transformation` → use `update_sql_transformation` PREREQUISITES: - The configuration row must already exist (use add_config_row for new rows) - You must know component_id, configuration_id, and configuration_row_id - For parameter updates: Review the component's row_configuration_schema using get_components - For storage updates: Ensure mappings are valid for row-level storage IMPORTANT CONSIDERATIONS: - Parameter updates are PARTIAL - only specify fields you want to change - parameter_updates supports granular operations: set individual keys, replace strings, or remove keys - Parameters must conform to the component's row_configuration_schema (not root schema) - Validate schemas before calling: use get_components to retrieve row_configuration_schema - Each row operates independently - changes to one row don't affect others - Row-level storage is separate from root-level storage configuration WORKFLOW: 1. Retrieve current configuration using get_configs to see existing rows 2. Identify the specific row to modify by its configuration_row…

Updates the description for a Keboola storage item. This tool supports three item types, inferred from the provided item_id: - bucket: item_id = "in.c-bucket" - table: item_id = "in.c-bucket.table" - column: item_id = "in.c-bucket.table.column" Usage examples (payload uses a list of DescriptionUpdate objects): - Update a bucket: updates=[DescriptionUpdate(item_id="in.c-my-bucket", description="New bucket description")] - Update a table: updates=[DescriptionUpdate(item_id="in.c-my-bucket.my-table", description="New table description")] - Update a column: updates=[DescriptionUpdate(item_id="in.c-my-bucket.my-table.my_column", description="New column description")]

Updates an existing flow configuration (either legacy `keboola.orchestrator` or conditional `keboola.flow`). PRE-REQUISITES: - Always use `get_flow_schema` (and `get_flow_examples`) for that flow type you want to update to follow the required structure and see the examples if unknown - Only pass `phases`/`tasks` when you want to replace them; omit to keep the existing ones unchanged RULES (ALL FLOWS): - `flow_type` must match the stored component id of the flow; do not switch flow types during update - `phases` and `tasks` must follow the schema for the selected flow type; include at least `id` and `name` - Tasks must reference existing component configurations; keep dependencies consistent - Always provide a clear `change_description` and surface any links returned in the response to the user CONDITIONAL FLOWS (`keboola.flow`): - Maintain a single entry phase and ensure every phase is reachable; connect phases via `next` transitions - No cycles or dangling phases; failed tasks already stop the flow, so only add retries/conditions if requested LEGACY FLOWS (`keboola.orchestrator`): - Phases run sequentially; tasks inside a phase run in parallel; `dependsOn` references other phase ids - Use `continueOnFailure` or best-effort patterns only when the user explicitly asks for them WHEN TO USE: - Renaming a flow, updating descriptions, adding/removing phases or tasks, adjusting dependencies, or enabling/disabling flow execution

Updates the description of the current Keboola project.

Updates an existing SQL transformation configuration by modifying its SQL code, storage mappings, name or description. This tool allows PARTIAL parameter updates for transformation SQL blocks and code - you only need to provide the operations you want to perform. All other fields will remain unchanged. Use this for modifying SQL transformations created with create_sql_transformation. WHEN TO USE: - SQL transformations only (Snowflake/BigQuery); use update_config for Python/R/DuckDB transformations - Modifying SQL queries in transformation (add/edit/remove SQL statements) - Updating transformation block or code block names - Changing input/output table mappings for the transformation - Updating the transformation name or description - Any combination of the above PREREQUISITES: - Transformation must already exist (use create_sql_transformation for new transformations) - You must know the configuration_id of the transformation - SQL dialect is determined automatically from the workspace - CRITICAL: Use get_configs first to see the current transformation structure and get block_id/code_id values TRANSFORMATION STRUCTURE: A transformation has this hierarchy: transformation └─ blocks[] - List of transformation blocks (each has a unique block_id) └─ block.name - Descriptive name for the block └─ block.codes[] - List of code blocks within the block (each has a unique code_id) └─ code.name - Descriptive name for the code block └─ code.script - SQL script (string with SQL statements) Example structure from get_configs: { "blocks": [ { "id": "b0", ← block_id needed for operations (format: b{index}) "name": "Data Preparation", "codes": [ { "id": "b0.c0", ← code_id needed for operations (format: b{block_index}.c{code_index}) "name": "Load customers", "script": "SELECT * FROM customers WHERE status = 'active';" } ] } ] } PARAMETER UPDATE OPERATIONS: All operat…

Performs best-effort semantic validation of an SQL query against one or more semantic models and compares it with the expected semantic objects provided. RETURNS: - `validation_auto_detected`: semantic validation built from objects heuristically detected in the SQL - `validation_detected_from_expected`: semantic validation built only from explicitly provided expected object IDs - expected semantic objects that were matched or missing in the auto-detected result - unexpected auto-detected objects outside the expected semantic scope LIMITATIONS: - Detection is heuristic and based on string matching over SQL and semantic metadata. - The tool does not parse SQL semantically and does not execute the query. - Auto-detected objects, missing objects, and relationship matches may therefore be imperfect. - Use the result as a best-effort semantic check, not as a formal proof that the query is correct. CONSIDERATIONS: - Prefer calling this tool before executing any SQL that touches semantic objects. - This tool confirms the SQL dialect, surfaces semantic constraint violations, and provides post-execution checks. - Only proceed to query_data once this tool returns valid=True and violations is empty. If violations are found, fix the query first or consider the limitations of this tool. - Entries under `semantic_models` carry `scope`/`project_id`/`source_project_id`/ `target_project_ids` -- see `get_semantic_context`'s CONSIDERATIONS for what they mean. A "targeted"/"organization"-scope model does not guarantee the query is actually runnable from every project that can see it; this tool validates against the semantic layer, not against whether the underlying Storage tables are reachable here. Pass `resolve_data_location=True` to check that directly for every used dataset instead of inferring it from scope alone. WHEN TO USE: - Before generating or approving a query that should follow a semantic model. - When you want to validate a SQL query against the semantic objects befo…