com.keboola/mcp

Creates a component configuration row in the specified configuration_id, using the specified name, component ID, configuration JSON, and description. BEFORE CALLING - REQUIRED STEPS: 1. Call `get_components([component_id])` to retrieve the component's `configuration_row_schema`. 2. Read `configuration_row_schema.required` to find ALL mandatory top-level fields. 3. Call `get_config_examples(component_id)` to see real-world row parameter examples. 4. Populate `parameters` with every required field before calling this tool. Skipping these steps will cause a schema validation error. USAGE: - Use when you want to create a new row configuration for a specific component configuration. WHEN NOT TO USE: - `keboola.orchestrator` / `keboola.flow` → use `create_flow` / `create_conditional_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 `create_sql_transformation` EXAMPLES: - user_input: `Create a new configuration row for component X with these settings` - set the component_id, configuration_id and configuration parameters accordingly - returns the created component configuration if successful.

Creates a new conditional flow configuration using `keboola.flow`. PRE-REQUISITES: - Always use `get_flow_schema` with flow_type="keboola.flow" and review `get_flow_examples` if unknown - Gather component configuration IDs for all tasks you include RULES: - `phases` and `tasks` must follow the keboola.flow schema; each entry needs `id` and `name` - Exactly one entry phase (no incoming transitions); all phases must be reachable - Connect phases via `next` transitions; no cycles or dangling phases; empty `next` means flow end - Task/phase failures already stop the flow; add retries/conditions only if the user requests them - Always share the returned links with the user WHEN TO USE: - Flows needing branching, conditions, retries, or notifications - Default choice when user simply says "create a flow," unless they explicitly want legacy orchestrator behavior

Creates a root component configuration using the specified name, component ID, configuration JSON, and 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 Python (`keboola.python-transformation-v2`), R (`keboola.r-transformation-v2`) and DuckDB (`keboola.duckdb-transformation`) transformations. BEFORE CALLING - REQUIRED STEPS: 1. Call `get_components([component_id])` to retrieve the component's `configuration_schema`. 2. Read `configuration_schema.required` to find ALL mandatory top-level fields. 3. Call `get_config_examples(component_id)` to see real-world parameter examples. 4. Populate `parameters` with every required field before calling this tool. Skipping these steps will cause a schema validation error. USAGE: - Use when you want to create a new root configuration for a specific component. WHEN NOT TO USE: - `keboola.orchestrator` / `keboola.flow` → use `create_flow` / `create_conditional_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 `create_sql_transformation` EXAMPLES: - user_input: `Create a new configuration for component X with these settings` - set the component_id and configuration parameters accordingly - returns the created component configuration if successful.

Creates a new legacy (non-conditional) flow using `keboola.orchestrator`. PRE-REQUISITES: - Always use `get_flow_schema` with flow_type="keboola.orchestrator" and review `get_flow_examples` if unknown - Collect component configuration IDs for every task you include RULES: - `phases` and `tasks` must follow the orchestrator schema; each entry must include `id` and `name` - Phases run sequentially; tasks inside a phase run in parallel - Use `dependsOn` on phases to sequence them; reference other phase ids - Always share the returned links with the user WHEN TO USE: - Simple/linear orchestrations without branching or conditions - ETL/ELT pipelines where phases just need ordering and parallel task groups

Generates an OAuth authorization URL for a Keboola component configuration. When using this tool, be very concise in your response. Just guide the user to click the authorization link. Note that this tool should be called specifically for the OAuth-requiring components after their configuration is created e.g. keboola.ex-google-analytics-v4 and keboola.ex-gmail.

Creates a brand-new Keboola project for a session that has no Keboola credentials yet, and signs this session in to it. Use this ONLY when a tool call has reported that the session has no Keboola credentials and the user has no project/token to give you -- it is how a first-time user gets started without leaving the conversation. Never call it to add a project to a session that already works: it refuses, because it would replace the credentials that session is using. Not every Keboola stack offers this -- it is gated by a stack feature. On a stack without it the tool says so and the user has to bring their own project instead; that is a fact about the stack, so do not retry. The project starts out owned by nobody. Show the user the returned `confirm_url` and tell them to open it: signing in there makes the project permanently theirs. Until they do, the project is temporary and Keboola may reclaim it, and once they do, the session created here is revoked and they continue with their own login. Data tools work against the new project in the meantime.

Mints a one-time HTTPS token on a python-js **prod** data app so the caller can clone, pull, and push to the app's managed git repo over HTTPS. **Always call against the prod app's configuration_id** — drafts have no managed repo of their own, so calling this on a draft fails. The prod app is the canonical repo owner; drafts iterate against branches of that same repo. **MCP never runs git on your behalf.** All git work — clone, branch, commit, push, merge, branch-delete — is yours. This tool only mints credentials. Returns a ready-to-use `git_clone_url` of the form `https://kai:<secret>@<host>/<path>.git` plus the raw `secret`. The token is returned **only** at creation — the platform cannot return it again on any subsequent read. Stash the URL (or the secret) somewhere the LLM can reuse for the rest of the session. The data-science API accepts multiple credentials per app, so calling this again mints an additional token without invalidating any tokens already held by other clients. ## When to call 1. **Right after `modify_python_js_data_app` create of a prod app** — the new prod has a managed repo but no credentials yet. Call this tool with the new app's `configuration_id` to enable git access. (Note: when creating a **draft**, the prod-side token is minted and embedded into the returned `git_clone_url` automatically — no separate call needed.) 2. **Recovery when the cached token is gone / continuing an unfinished draft** — e.g., a fresh sandbox continuing yesterday's work, with the previous sandbox's filesystem wiped. The cached `git_clone_url` is lost; the configuration ID for the prod app is all you have. Call this tool with the **prod app's** `configuration_id` to mint a fresh token (drafts have no managed repo, so always mint against prod). Existing credentials remain valid, so other clients are not disrupted. ## Constraints - Only python-js prod data apps have a managed git repo. Streamlit apps reject the call with a clear e…

Creates an SQL transformation using the specified name, SQL query following the current SQL dialect, a detailed description, and a list of created table names. CONSIDERATIONS: - By default, SQL transformation must create at least one table to produce a result; omit only if the user explicitly indicates that no table creation is needed. - Each SQL code block must include descriptive name that reflects its purpose and group one or more executable semantically related SQL statements. - Each SQL query statement within a code block must be executable and follow the current SQL dialect. - Use delimited identifiers for the current SQL dialect for all identifiers and FQN references. - When referring to the input tables within the SQL query, use fully qualified table names, which can be retrieved using appropriate tools. - When creating a new table within the SQL query (e.g. CREATE TABLE ...): use only the table name with delimited identifiers, without the fully qualified path; add the plain table name without delimiters to the `created_table_names` list. - Unless otherwise specified by user, transformation name and description are generated based on the SQL query and user intent. - If there are 20 or more SQL transformations in the project, consider organizing them with a folder: existing folder names are surfaced in the response's change_summary — use one of them or create a new one. USAGE: - Use when you want to create a new SQL transformation. - This is THE tool for creating `keboola.snowflake-transformation` and `keboola.google-bigquery-transformation` components (do NOT use `create_config` for these); the transformation ID is derived automatically from the workspace SQL dialect. - Snowflake/BigQuery only. For Python, R, or DuckDB transformations, use `create_config` with the appropriate `component_id` instead — this tool cannot create them. EXAMPLES: - user_input: `Can you create a new transformation out of this sql query?` - set the sql_cod…

Deletes a python-js DRAFT data app — both the data-app instance (DSAPI) and its Storage configuration. **MCP never runs git on your behalf.** Deleting the feature branch on the remote is your job; this tool only tears down the draft config and its data-app instance. WHEN TO CALL: at the end of a promote-to-prod sequence, after you have merged the draft's branch into `main`, pushed, deleted the feature branch from the remote, and redeployed the prod app. The Keboola UI lists drafts under their parent prod app; once you call this tool, the draft disappears from that list. WHAT THIS TOOL REFUSES: - prod apps (no `isDraft` flag) — protects against accidental prod deletion; - Streamlit apps — they have no draft concept. WHAT THIS TOOL DOES NOT DO: - Run git. Deleting the feature branch on the remote is your job. - Revoke the prod-side git credential minted when the draft was created. Credential rotation is the user's job via the Keboola UI. After a successful call, pivot back to the parent prod app (its configuration_id is returned in the response) or to `get_data_apps` for further work.

Deploys/redeploys a data app or stops a running data app in the Keboola environment asynchronously, given the action and the configuration ID. **MCP never runs git on your behalf.** All git work — clone, branch, commit, push, merge, branch-delete — is yours. This tool only triggers deploys against existing git state. ## Mode (python-js apps) - `mode='dev'` deploys the target as a **dev version of the data app** — the runtime uses a development `setup.sh` (hot reload) and the data-app proxy enables an auto-auth path so an iframe preview can render without a manual login. Only meaningful on **draft** configs (python-js apps with `isDraft=true`). - For prod redeploys (including after merging a draft's branch into `main`), use no `mode` — the prod app picks up the current `main`. - The branch a draft deploys from is pinned in `parameters.dataApp.git.branch` at create time; there is no deploy-time override. - python-js apps do NOT fetch a Storage `configVersion` for deployment (their source lives in git, not in the Storage configuration); this is handled automatically. ## Streamlit apps Streamlit apps have no managed git repo, so `mode` has no effect on the deployed app. `mode=None` is the expected call shape. ## General considerations - Redeploying a data app takes some time, and the app may temporarily report status "stopped" during the restart. - After deployment, the deployment info includes the app URL and the latest logs to help diagnose in-app errors.

Answers a question using the Keboola documentation as a source.

Returns list of component IDs that match the given query. WHEN TO USE: - Use when you want to find the component for a specific purpose. USAGE EXAMPLES: - user_input: "I am looking for a salesforce extractor component" → Returns a list of component IDs that match the query, ordered by relevance/best match.

Lists the Keboola projects the current login can access across the stack, each with its SQL dialect and organization. Only call this when a data tool call has actually failed asking you to confirm a project scope -- the session may already be pre-scoped (e.g. the user chose specific projects at `login` time), in which case data tools already work and this call would just be extra, unnecessary API traffic. When a scope genuinely is needed: present the projects, ask whether the user wants to work across all of them or a subset, then call `set_project_scope` with their choice. This tool compacts several API calls (token introspection plus a per-project token verify for the SQL dialect and organization) into one result, so the assistant does not need a separate get_project_info call per project. Pass with_llm_instruction=true on the first call to also receive the base working instructions grouped by dialect.

Lists buckets or retrieves full details of specific buckets, including descriptions, lineage references (created/updated by), and links. WHEN NOT TO USE: - Do NOT call with `bucket_ids=[]` just to find a bucket by name. Use `search` with item_types=["bucket"] instead. - Only use `bucket_ids=[]` when you need a complete inventory of all buckets in the project. EXAMPLES: - `bucket_ids=[]` → summaries of all buckets in the project - `bucket_ids=["id1", ...]` → full details of the buckets with the specified IDs

Retrieves detailed information about one or more components by their IDs. RETURNS FOR EACH COMPONENT: - Component metadata (name, type, description) - Documentation and usage instructions - Configuration JSON schema (required for creating/updating configurations) - Links to component dashboard in Keboola UI WHEN TO USE: - Before creating a new configuration: fetch the component to get its configuration schema - Before updating a configuration: fetch the component to understand valid configuration options - When user asks about component capabilities or documentation PREREQUISITES: - You must know the component_id(s). If unknown, first use `find_component_id` or `docs` tool to discover them. EXAMPLES: - User: "Create a generic extractor configuration" → First call `find_component_id` to get the component_id, then call this tool to get the schema - User: "What options does the Snowflake writer support?" → Call this tool with the Snowflake writer component_id to retrieve its documentation and schema

Retrieves sample configuration examples for a specific component. USAGE: - Use before calling `create_config` or `add_config_row` to understand the expected parameters structure. - Use when you want to see example configurations for a specific component. EXAMPLES: - user_input: `Show me example configurations for component X` - set the component_id parameter accordingly - returns a markdown formatted string with configuration examples

Retrieves component configurations in the project with optional filtering. Can list summaries of multiple configurations (grouped by component) or retrieve full details for specific configurations. Returns a list of components, each containing: - Component metadata (ID, name, type, description) - Configurations for that component (summaries by default, full details if requested) - Links to the Keboola UI PARAMETER BEHAVIOR: - If configs is provided (non-empty): Returns FULL details ONLY for those configs. - Else if component_ids is provided (non-empty): Lists config summaries for those components. - Else: Lists configs based on component_types (all types if empty). WHEN TO USE: - For listing: Use component_types/component_ids. - For details: Use configs (can handle multiple). WHEN NOT TO USE: - Do NOT list all configs just to find a configuration by name. Use `search` with item_types=["configuration", "transformation"] instead. - Only use broad listing (empty component_types and component_ids) when you need a complete inventory of all configurations in the project. EXAMPLES: - List all configs (summaries): component_types=[], component_ids=[] - List extractors (summaries): component_types=["extractor"] - Get details for specific configs: configs=[{"component_id": "keboola.ex-db-mysql", "configuration_id": "12345"}]

Lists summaries of data apps in the project given the limit and offset or gets details of a data apps by providing their configuration IDs. WHEN NOT TO USE: - Do NOT list all data apps just to find one by name. Use `search` with item_types=["data-app"] instead. - Only list all data apps when you need a complete inventory. Considerations: - If configuration_ids are provided, the tool will return details of the data apps by their configuration IDs. - If no configuration_ids are provided, the tool will list all data apps in the project given the limit and offset. - Data App detail contains configuration, metadata, source code, links, and deployment info along with the latest data app logs to investigate in-app errors. The logs may be updated after opening the data app URL. - `deployment_info.last_run` carries the outcome of the most recent deployment attempt. For an app that fails to start, check its `failure_reason`/`failure_message` FIRST — they cover setup-phase failures (e.g. invalid secrets, git clone errors, failing setup scripts) that happen before the container starts and therefore never appear in the regular logs. - `repo_url` (managed git repo URL for python-js apps) is ONLY populated on the detail path (when `configuration_ids` is provided). The inventory list always returns `repo_url=None`, even for python-js apps with a managed repo — to retrieve the URL, call this tool again with the target `configuration_ids`. - When called with `configuration_ids=[<prod-cfg>]` for a python-js **prod** app, the response includes a `drafts: [...]` array of every draft (configs with `isDraft=true` and `parentConfigurationId == <prod-cfg>`) currently in the project. Drafts in trash are not included. Use this to discover existing drafts when continuing a previously abandoned iteration (Scenario C in `modify_python_js_data_app`). The array is empty for drafts themselves and for Streamlit apps.

Retrieves examples of valid flow configurations. PRE-REQUISITES: - Unknown examples for the target flow type: `keboola.flow` (conditional) or `keboola.orchestrator` (legacy) to help build the specific flow configuration by mirroring the structure/fields. RULES: - Conditional-flow examples require conditional flows to be enabled; otherwise use legacy orchestrator examples - Present the examples or cite unavailability to the user

Returns the JSON schema for the given flow type (markdown). PRE-REQUISITES: - Unknown schema for the target flow type: `keboola.flow` (conditional) or `keboola.orchestrator` (legacy) RULES: - Projects without conditional flows enabled cannot request `keboola.flow` schema - Use the returned schema to shape `phases` and `tasks` for `create_flow` / `create_conditional_flow` / `update_flow`

Lists flows or retrieves full details for specific flows. WHEN NOT TO USE: - Do NOT call with `flow_ids=[]` just to find a flow by name. Use `search` with item_types=["flow"] instead. - Only use `flow_ids=[]` when you need a complete list of all flows in the project. OPTIONS: - `flow_ids=[]` → summaries of all flows in the project - `flow_ids=["id1", ...]` → full details (including phases/tasks) for those flows

Retrieves job execution information from the Keboola project. CONTEXT: Jobs in Keboola are execution records of components (extractors, transformations, writers, flows). Each job represents a single run with its status, timing, configuration, and results. TWO MODES OF OPERATION (controlled by job_ids parameter): MODE 1: GET DETAILS FOR SPECIFIC JOBS (job_ids is non-empty) - Provide one or more job IDs: job_ids=["12345", "67890"] - Returns: FULL details for each job including status, config_data, results, timing, and metadata - Ignores: All filtering/sorting parameters (status, component_id, config_id, limit, offset, sort_by, sort_order) - Use when: You know specific job IDs and need complete information about them MODE 2: LIST/SEARCH JOBS (job_ids is empty) - Leave job_ids empty: job_ids=[] - Returns: SUMMARY list of jobs (id, status, component_id, config_id, timing only - no config_data or results) - Supports: Filtering by status/component_id/config_id, pagination with limit/offset, sorting - Use when: You need to find jobs, see recent executions, or monitor job history DECISION GUIDE: - Start with MODE 2 (list) to find jobs → then use MODE 1 (details) if you need full information - If you already know job IDs → use MODE 1 directly - For monitoring/browsing → use MODE 2 with filters NOTE: Jobs cannot be found by name using the `search` tool. However, always use the filtering parameters (status, component_id, config_id) to narrow results rather than listing all jobs with no filters. If you need to find jobs for a specific configuration but only know its name, first use `search` to find the configuration ID, then filter jobs by that config_id. COMMON WORKFLOWS: 1. Find failed jobs: job_ids=[], status="error" → identify problematic job IDs → get details with MODE 1 2. Check recent runs: job_ids=[], component_id="...", limit=10 → see latest executions 3. Monitor specific job: job_ids=["123"] → poll for status and results 4. Troubleshoot config: job_ids=[], comp…

Retrieves structured information about the current project, including essential context and base instructions for working with it (e.g., transformations, components, workflows, and dependencies). Always call this tool at least once at the start of a conversation to establish the project context before using other tools. Reports on exactly one project; pass `project_id` to pick which when the session is scoped to 2+ projects.

Loads semantic objects grouped by semantic object type. CONSIDERATIONS: - If a selection has empty `ids`, the tool returns all objects of that type in compact form. - If a selection has non-empty `ids`, the tool returns only those specific objects with full attributes. - `semantic_model_ids` optionally narrows the lookup to specific semantic models. - An object returned here carries `scope` ("project", "organization", or "targeted"), `project_id` (the project it was created in -- present regardless of scope), `source_project_id` (which project an "organization"-scope object came from, if known), and `target_project_ids` (the sibling projects granted read access, for "targeted" scope). This is reported only for an object that appears in the current project's listing or that was loaded by id -- an "organization"-scope object owned by another project is not surfaced by the listing path today, only via a direct id lookup. `scope` describes visibility of the metastore object itself, not whether its underlying Keboola Storage table is actually reachable from every project that can see it -- a "targeted"/"organization" object's data may still need its bucket separately shared and linked (`get_shared_buckets`/`link_shared_bucket`) before a query against it will work outside the owning project. Pass `resolve_data_location=True` to check this directly instead of inferring it from scope alone. - An object's `scope_elevation_requested_at` being set means a project has asked an organization admin to promote it from "project" to "organization" scope, and the request is still pending. Treat this as a forward-looking signal: once approved, the object (a semantic-model's promotion also carries its datasets' underlying tables along) becomes visible org-wide, which may require separately sharing the physical data too -- promotion alone does not do that automatically. WHEN TO USE: - When you already know IDs of the semantic objects you want to load an…

Returns JSON schemas for the requested semantic object types. WHEN TO USE: - When you want to know the JSON schema of a semantic object type, e.g. before searching something specific.

Lists buckets shared with this project by other Keboola projects that are not necessarily linked into this project yet (the Data Catalog "Shared with me" view). Use this to answer "what data is shared with this project?" or "what could I link?" — `get_buckets` only returns buckets already in this project (including already-linked ones). Results are paginated (`limit`/`offset`) because the number of shared buckets can be large for projects in big organizations — always check `total_count` and the `message` to see whether more results exist, and page through with `offset` rather than assuming a single call returns everything. Use `link_shared_bucket` to link a shared bucket returned here into this project.

Lists tables in buckets or retrieves full details of specific tables, including fully qualified database name, column definitions, lineage references (created/updated by) and links. WHEN NOT TO USE: - Do NOT list tables across buckets just to find a table by name. Use `search` with item_types=["table"] instead — it also matches column names and descriptions. - Only use `bucket_ids` listing when you need all tables in specific known buckets. RETURNS: - With `bucket_ids`: Summaries of tables (ID, name, description, primary key). - With `table_ids`: Full details including columns, data types, and fully qualified database names. - With `table_ids` and `include_usage`: Full details plus components / transformations that use the tables in their input / output mappings. Use only when explicitly needed or evident from context; usage calculation might be demanding in big projects. COLUMN DATA TYPES: - database_native_type: The actual type in the storage backend (Snowflake, BigQuery, etc.) with precision, scale, and other implementation details - keboola_base_type: Standardized type indicating the semantic data type. May not always be available. When present, it reveals the actual type of data stored in the column - for example, a column with database_native_type VARCHAR might have keboola_base_type INTEGER, indicating it stores integer values despite being stored as text in the backend. QUERYABILITY RULE: - A table is directly queryable via query_data tool only if fullyQualifiedName is present and non-null in the response. - If fullyQualifiedName is absent or null (e.g. for linked/alias tables from other projects), the table cannot be queried via SQL from this workspace. - Do not attempt to construct or guess the FQN — it will not work. In that case, inform the user of the limitation immediately. EXAMPLES: - `bucket_ids=["id1", ...]` → summary info of the tables in the buckets with the specified IDs - `table_ids=["id1", ...]` → detailed info of the…

Links a bucket shared with this project (found via `get_shared_buckets`) into this project as a new local bucket, so its tables become directly queryable/joinable like any other bucket in the project. Not idempotent: calling this again with the same `target_bucket_name` fails once that name already exists, so don't retry blindly on error without checking whether the link succeeded. Note: unlike `get_buckets`, the returned bucket does not participate in this server's prod/dev branch-shading (its `branch_id` is not resolved) -- linking always targets the caller's current branch context directly.

Updates an existing flow configuration (either legacy `keboola.orchestrator` or conditional `keboola.flow`) or manages schedules for this 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 - A flow can have multiple schedules for automation runs. Add/update/remove schedules only if requested. - When updating a flow or a schedule, specify only the fields you want to update, others will be kept unchanged. 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, updating schedules, adjusting dependencies, or enabling/disabling flow execution

Creates or updates a python-js data app. Two-app project model. Every python-js project has a persistent **prod app** that owns the only managed git repository for the project, and zero or more **drafts** parented to that prod app. A draft is a Storage configuration with `parameters.dataApp.isDraft=true` and `parameters.dataApp.parentConfigurationId=<prod cfg id>`; it's an *external-git* app that clones the parent prod's repo at a pinned branch on every deploy. Drafts are surfaced in the Keboola UI under their parent prod app. Use `deploy_data_app(mode='dev')` to deploy a draft as a dev version of the data app (hot reload + auto-auth for iframe preview); use `delete_python_js_data_app_draft` to tear a draft down after its branch has been promoted. **MCP never runs git on your behalf.** All git work — clone, branch, commit, push, merge, branch-delete — is yours. MCP gives you authenticated clone URLs and manages configs/deploys; it never invokes git. **The draft flow below is mandatory — never edit prod source directly.** Every source-code change goes through a draft branch that the user previews and explicitly approves first. NEVER push directly to `main`: `main` only ever advances by merging an approved draft branch, and only after the user has approved that draft's preview. Three scenarios the agent has to distinguish: ## Scenario A — Create a brand-new data app 1. `modify_python_js_data_app(slug='demo')` → `(configuration_id=PROD, repo_url=R)`. PROD owns the only managed repo for this app. 2. `modify_python_js_data_app(slug='demo-draft', parent_configuration_id=PROD)` → `(configuration_id=DRAFT, repo_url=R, git_clone_url=U, branch='draft-<hex>')`. The default branch is generated fresh per draft (`draft-<hex>`) so it can never collide with a branch left behind by an earlier draft. Override with `branch=<name>` for a descriptive name — if you do, YOU own uniqueness (see step 3). 3. YOU: `git clone U`; `git checkout -b <branch>` (the repo of a…

Creates or updates a Streamlit data app. Considerations: - The `source_code` parameter must be a complete and runnable Streamlit app. It must include a placeholder `{QUERY_DATA_FUNCTION}` where a `query_data` function will be injected. This function queries the workspace to get data, it accepts a string of SQL query following current sql dialect and returns a pandas DataFrame with the results from the workspace. - Write SQL queries so they are compatible with the current workspace backend, you can ensure this by using the `query_data` tool to inspect the data in the workspace before using it in the data app. - If you're updating an existing data app, provide the `configuration_id` parameter and the `change_description` parameter. To keep existing data app values during an update, leave them as empty strings, lists, or None appropriately based on the parameter type. - After creating or updating a data app with this tool, ALWAYS call `deploy_data_app(action="deploy", configuration_id=...)` to start a new app or restart an existing app so changes take effect. Without this step, a newly created app will not start, and an existing app will keep running the previous deployment without the latest changes. - New apps use the HTTP basic authentication by default for security unless explicitly specified otherwise; when updating, set `authentication_type` to `default` to keep the existing authentication type configuration (including OIDC setups) unless explicitly specified otherwise. SQL & DATA TYPE RULES: - Use delimited identifiers for the current SQL dialect for all column names and aliases in SQL. Match the exact identifier case used in SQL when referencing columns in Python code. - `query_data` RETURNS ALL COLUMNS AS STRINGS regardless of SQL CAST. Always convert types in Python after loading: `df["col"] = pd.to_numeric(df["col"], errors="coerce").fillna(0)` and `df["date"] = pd.to_datetime(df["date"], errors="coerce")`.

Executes an SQL SELECT query to get the data from the underlying database. BEFORE QUERYING: * Always verify the table has a non-null fullyQualifiedName from get_tables tool. If it does not, the table is not SQL-accessible from this workspace — do not attempt the query and inform user. CRITICAL SQL REQUIREMENTS: * ALWAYS check the SQL dialect before constructing queries. * Do not include any comments in the SQL code * Use delimited identifiers and FQN format for the current SQL dialect. TABLE AND COLUMN REFERENCES: * Always use fully qualified table names in the exact FQN format provided by table information tools * Follow the identifier structure exactly as shown by table info tools for the current SQL dialect * For every column reference, call get_tables first and copy that column's `quotedName` value VERBATIM. Do not guess the name, re-case it, or hand-quote it yourself — use the exact `quotedName` from get_tables. * Snowflake case trap: unquoted identifiers fold to UPPERCASE while quoted identifiers are case-sensitive, so hand-quoting a guessed lowercase name (e.g. "date") fails with `invalid identifier` even though the column physically exists as DATE. The `quotedName` from get_tables already carries the correct case and dialect quoting, so copying it avoids this. CTE (WITH CLAUSE) RULES: * ALL column references in main query MUST match exact case used in the CTE * If you alias a column in a CTE, reference it under the aliased name in the subsequent queries * Define all column aliases explicitly in CTEs * Use delimited identifiers in both CTE definition and references to preserve case FUNCTION COMPATIBILITY: * Check data types before using date functions (DATE_TRUNC, EXTRACT require proper date/timestamp types) * Cast VARCHAR columns to appropriate types before using in date/numeric functions ERROR PREVENTION: * Keboola Storage stores empty cells as empty strings ('') rather than NULL — even for columns reported as VARCHAR/STRING with nullabl…

Starts a new job for a given component or transformation.

Executes a synchronous action for a component configuration or a component row configuration. WHEN TO USE: - For finding available values of a configuration field - For validating already configured values (e.g. testing a database connection) - For listing remote resources such as endpoints, schemas or tables

Searches for Keboola items (tables, buckets, components, configurations, transformations, flows, data-apps, etc.) in the current project and returns matching ID + metadata. This tool supports two complementary search types: 1) textual - Searches items by name, server-side (fast, independent of project size). - Tokenized full-text name matching, case- and diacritics-insensitive. Pass the plain name; do NOT build regex (rejected). It is NOT typo-corrected — misspellings may not match. - Prefers the current branch context; when nothing is found there, automatically widens the search to all branches of the project — such hits carry `branch_id`/`branch_name` so you can tell where they live. 2) config-based - Searches item configurations (JSON objects) by matching patterns against the configuration values converted to a string, optionally narrowed by JSON path `scopes`. - Returns also `match_scopes` with JSON paths and matched patterns per scope. THIS IS THE PRIMARY DISCOVERY TOOL. Always use it BEFORE any get_* tool when you need to find items by name or specific configuration content. Do NOT enumerate items with get_buckets, get_tables, get_configs, get_flows, or get_data_apps just to locate a specific item — use this tool instead. WHEN TO USE: - User asks to "find", "locate", or "search for" something by name, keyword, text pattern, configuration content or value - User mentions a partial name and you need to find the full item (e.g., "find the customer table") - User asks "what tables/configs/flows do I have with X in the name?" - You need to discover items before performing operations on them - User asks to "list all items with [name] or [configuration value/part] in it" - User asks where a value, table, component, specific configuration ID, or specific settings is used in components, data-apps, flows, or transformations - You need to trace lineage by searching for IDs referenced in configurations, or to find flows using a specific component, or find us…

Searches semantic models and semantic objects using regex patterns matched against their names, descriptions and stringified JSON attributes. Returns compact matches grouped by semantic model. Each match includes the semantic object type, the paths where the patterns matched, and compact object view. CONSIDERATIONS: - The search is case-insensitive by default. Use `case_sensitive=True` when exact casing matters. - The search is performed against semantic object names and data attributes which are stringified JSON objects following their corresponding JSON schema. - The search can be scoped to specific semantic models or semantic object types but prefer broader search without scoping unless required by the context. - Matches carry the same `scope`/`project_id`/`source_project_id`/`target_project_ids` fields as `get_semantic_context` -- see that tool's CONSIDERATIONS for what they mean and imply. WHEN TO USE: - When you need to discover which semantic objects are relevant to a user request. - When you know business terms, column names, metric fragments, or rule names, but not exact object UUIDs. - When you need to find semantic objects by keyword or values used in their attributes. WHEN NOT TO USE: - When you know the exact IDs. EXAMPLES: - Find semantic objects by business concepts for revenue or sales: `patterns=["revenue", "sales"]` - Find semantic objects using a Keboola table ID: `patterns=["out.c-sales-main.fact_orders"]` - Find semantic dataset for a certain table: `patterns=["in.c-sales-main.fact_orders"], semantic_types=["semantic-dataset"]` - Find semantic datasets that mention a column name: `patterns=["column_name"], semantic_types=["semantic-dataset"]` - Search semantic objects e.g. semantic metrics, relationships, and constraints using a certain semantic dataset: `patterns=["table-id-of-the-dataset"], semantic_types=["semantic-metric",` `"semantic-relationship", "semantic-constraint"]` - Search semantic constraints using e.g. certain se…

Scopes the current session to a set of Keboola projects. Mints a scoped access token (narrowed to `project_ids`, optionally read-only) that is used for the rest of the conversation. Read-only tools then run against every scoped project in a single call; write/modify/delete tools take a `project_id` argument naming which scoped project to target (required once 2+ projects are scoped). Call this when the user states which projects to work on; it can be called again any time to re-scope. On most transports the server does not remember this scope between calls: pass the returned `scope_token` as the `scope_token` argument on every subsequent tool call in this conversation to keep it in effect. Not needed for a local server or an OAuth-authenticated session, both of which persist the confirmed scope server-side instead -- `scope_token` is null there.