Keboola MCP

Keboola MCP Server

Connect your AI agents, MCP clients (Cursor, Claude, Windsurf, VS Code ...) and other AI assistants to Keboola. Expose data, transformations, SQL queries, and job triggers—no glue code required. Deliver the right data to agents when and where they need it.

Overview

Keboola MCP Server is an open-source bridge between your Keboola project and modern AI tools. It turns Keboola features—like storage access, SQL transformations, and job triggers—into callable tools for Claude, Cursor, CrewAI, LangChain, Amazon Q, and more.

• Quick Start
• Local Setup

Features

With the AI Agent and MCP Server, you can:

• Storage: Query tables directly and manage table or bucket descriptions
• Components: Create, List and inspect extractors, writers, data apps, and transformation configurations
• SQL: Create SQL transformations with natural language
• Jobs: Run components and transformations, and retrieve job execution details
• Flows: Build and manage workflow pipelines using Conditional Flows and Orchestrator Flows.
• Data Apps: Create, deploy and manage Keboola Data Apps displaying your queries over storage data — python-js apps on a Keboola-managed repository or on a customer GitHub repository (cloned through the organization's GitHub connection, no stored credential), and Streamlit apps.
• Metadata: Search, read, and update project documentation and object metadata using natural language
• Dev Branches: Work safely in development branches outside of production, where all operations are scoped to the selected branch.

---

🚀 Quick Start: Remote MCP Server (Easiest Way)

The easiest way to use Keboola MCP Server is through our Remote MCP Server. This hosted solution eliminates the need for local setup, configuration, or installation.

What is the Remote MCP Server?

Our remote server is hosted on every multi-tenant Keboola stack and supports OAuth authentication. You can connect to it from any AI assistant that supports remote Streamable HTTP connection and OAuth authentication.

How to Connect

1. Get your remote server URL: Navigate to your Keboola Project Settings → MCP Server tab
2. Copy the server URL: It will look like https://mcp. .keboola.com/mcp
3. Configure your AI assistant: Paste the URL into your AI assistant's MCP settings
4. Authenticate: You'll be prompted to log in with your Keboola account. Which project(s) to work on is chosen afterwards, in the conversation (e.g. "list my Keboola projects" / "use project X")

Supported Clients

• [Cursor](https://cursor.com): Use the "Install In Cursor" button in your project's MCP Server settings or click this button

• [Claude Desktop](https://claude.ai): Add the integration via Settings → Integrations
• [Claude Code](https://www.anthropic.com/): Install using claude mcp add --transport http keboola (see below for details)
• [Windsurf](https://windsurf.ai): Configure with the remote server URL
• [Make](https://make.com): Configure with the remote server URL
• Other MCP clients: Configure with the remote server URL

Claude Code Setup

Claude Code is a command-line interface tool that allows you to interact with Claude using your terminal. You can install the Keboola MCP Server integration using a simple command.

Installation:

Run the following command in your terminal, replacing with your Keboola region:

claude mcp add --transport http keboola https://mcp.<YOUR_REGION>.keboola.com/mcp

Region-specific commands:

Usage:

Once installed, you can use the Keboola MCP Server in Claude Code by typing /mcp in your conversation and selecting the Keboola tools you want to use.

Authentication:

When you first use the Keboola MCP Server in Claude Code, a browser window will open prompting you to:

1. Log in with your Keboola account
2. Authorize the connection

After authentication, you can start using Keboola tools directly from Claude Code. Project selection happens afterward, in the conversation — just ask Claude which Keboola project(s) to use.

For detailed setup instructions and region-specific URLs, see our Remote Server Setup documentation.

Using Development Branches

You can work safely in Keboola development branches without affecting your production data. The remotely hosted MCP Servers respect the KBC_BRANCH_ID parameter and will scope all operations to the specified branch. You can find the development branch ID in the URL when navigating to the development branch in the UI, for example: https://connection.us-east4.gcp.keboola.com/admin/projects/PROJECT_ID/branch/BRANCH_ID/dashboard. The branch ID must be included in each request using the header X-Branch-Id: , otherwise the MCP Server uses production branch as default. This should be managed by the AI client or the environment handling the server connection.

Tool Authorization and Access Control

When using HTTP-based transports (Streamable HTTP), you can control which tools are available to clients using HTTP headers. This is useful for restricting AI agent capabilities or enforcing compliance policies.

Authorization Headers

Filter Behavior

Filters apply in order: allowed → read-only intersection → disallowed exclusion. Empty headers = no restriction.

Read-Only Tools

Read-only tools are those annotated with readOnlyHint=True. These tools only retrieve information without making any changes to your Keboola project. For the current list of read-only tools, see the TOOLS.md file which is an auto-generated snapshot of the actual tool set.

Example: Read-Only Access

X-Read-Only-Mode: true

Deferred Tool Loading

Claude Code / Claude Agent SDK clients that register the server with alwaysLoad: true keep these tools deferred behind tool search instead of loading their definitions up front. The header only changes the tools/list metadata — it does not hide or authorize tools. Empty header or unknown tool names = no change.

For detailed documentation, see developers.keboola.com/integrate/mcp/#tool-authorization-and-access-control.

Row-Level and Column-Level Security

Row- and column-level policies are Keboola Metastore objects (rls-policy, cls-policy), written through the Metastore API (the kbagent rls / kbagent cls commands are not in any kbagent release yet). This server neither reads nor applies them. In a project that has the row-level-security feature it creates its workspace (the mcp-workspace- configuration of the keboola.mcp-server-tool component) with the Connection login type governed. A governed workspace has no credentials: only the Query Service can read it, and the Query Service filters every query_data result by the policies of the project. There is no rewriting in this server and no fallback: what the Query Service refuses, query_data returns as an error.

• What turns it on. The project feature is checked by this server only; Connection needs no feature or role to create a governed workspace (Snowflake or BigQuery, no public key). The stack's Connection must accept the login type governed for the project's backend: a stack that does not refuses the create, and then every tool that needs the workspace fails (there is no fallback to an ordinary workspace). Enforcement on BigQuery is not verified end to end on a production stack. An older ordinary MCP workspace is not deleted: it is skipped as soon as the feature is on. With the feature on, a workspace_schema or X-Workspace-Id pin is accepted only for a governed workspace (an ordinary one would read around the policies), so a pin to the old workspace, or to a data app's own ordinary workspace, is refused; delete the old one.
• Deny by default. A table that neither an rls-policy nor a cls-policy covers is refused for an administrator (the agent sees Row-level security does not allow this query) and reads as no rows for an ordinary reader such as a data app end user (a "*" rule opens a table to every identified reader). A cls-policy alone opens its table: all rows, only its columns, for the readers it names; any other reader is refused. A statement that reads no table (SELECT 1) runs.
• Refused statements. A governed statement is refused (403, the same generic text for every reason) when it uses IDENTIFIER(), TABLE() outside FROM, an AI function (AI_*, BigQuery AI.*), TO_FILE, READ_CSV / READ_PARQUET, SECRET, a session-context function (CURRENT_USER, CURRENT_ROLE, CURRENT_STATEMENT, ...), NEXTVAL, $x or @@x, a control character, or an unquoted name with a non-ASCII character or $$, or when it is over 32 KiB, 200 CTEs or 300 table references. CURRENT_DATE, CURRENT_TIME and CURRENT_TIMESTAMP stay allowed (as of Query Service 1.25 and policy engine 0.1.8). A 503 Row-level security could not be applied to this workspace means nothing ran because the policies could not be applied; it can be transient. A failed governed statement returns The statement failed. Its error text is not shown for a workspace with row-level security.
• Who is the reader. The Query Service resolves the reader from the administrator's own token of the project: the programmatic token this server forwards (kbc_at_ / kbc_pat_, including the child PAT of a multi-project scope, sent with X-KBC-ProjectId) or an administrator's own master Storage token. Any other token (an integration, a data app, Kai) names no end user, has no verified identity and reads nothing from a governed table. The administrator's subject is keboola| and the identity carries no groups, so group rules never match.
• Bindings. Without a binding a workspace gets every policy of the project, and this server never creates one. To give a workspace only some policies, bind them to its KID: KID: :project- :workspace- (a workspace of the default branch; a branch workspace also has branch- before project). The stack id is the one the Query Service is configure