get_bucketsLABSCO SUMMARY
Restrict the tool list per client, in a header.
Most servers give every client the same tools and hope the prompt holds. Here X-Allowed-Tools and X-Read-Only-Mode decide it at the connection, so an analyst's agent and a pipeline-building agent can hit the same deployment and see different surfaces — enforced, not requested. The local backend is the other thing worth knowing about: the same tools over a directory of CSVs and DuckDB, with the platform-only tools unregistered rather than failing, which makes it a real way to work before a project exists.
What it is
Keboola's open-source MCP server for a Keboola project. It turns storage access, SQL transformations and job triggers into tools, and Keboola hosts it on every stack. Two things distinguish this from a plain API wrapper: which tools a client is offered can be restricted per connection, and it can run against local files instead of the platform.
What you get
- Storage and querying — get_buckets, get_tables, and query_data running SQL against the project's warehouse
- Configurations and jobs — get_configs, create_config, run_job, get_job and list_jobs
- Transformations and orchestration — create_sql_transformation, update_sql_transformation, create_flow, update_flow and create_conditional_flow
- Finding your way around — search, get_project_info, get_accessible_projects and set_project_scope, so project selection happens in the conversation rather than in configuration
- Data apps — modify_data_app for Streamlit, and a python-js pipeline built around a managed git repository: modify_python_js_data_app creates the prod app and drafts against it, create_python_js_data_app_git_credential mints a one-time HTTPS token, deploy_data_app deploys or stops, get_data_apps lists a prod app together with its drafts, and delete_python_js_data_app_draft cleans up after promotion
- Per-client tool authorization over HTTP headers — X-Allowed-Tools names what a client may call, X-Disallowed-Tools excludes specific tools, and X-Read-Only-Mode restricts it to the read-only ones
- A --local-backend mode that swaps every platform call for a local one: get_tables scans a directory of CSVs, query_data runs DuckDB over them, search looks through filenames and headers, and setup_component and run_component build and run a Keboola component locally in Docker
- In local mode the platform-only tools are simply not registered, so run_job, deploy_data_app, create_flow and the transformation tools never appear in the client's tool list
- create_oauth_url for the components that need an authorization round trip
Requirements
A Keboola account and project. Running it locally is a one-time browser login with no token to paste — keboola_mcp_server login — or a storage token in KBC_STORAGE_TOKEN with KBC_PROJECT_ID, KBC_STORAGE_API_URL and the workspace named by KBC_WORKSPACE_SCHEMA or KBC_WORKSPACE_ID. KBC_BRANCH_ID scopes everything to a development branch, and the remote server takes the same thing as an X-Branch-Id header. A server deployed inside Keboola's own infrastructure can authenticate with a projected Kubernetes ServiceAccount token at KBC_KUBERNETES_TOKEN_PATH — locally-run servers have no such token, so that path is not available to them. One naming gotcha: the full tool name includes the server name and must stay under about sixty characters, so a long server name gets tools filtered out in some clients.
Setup effort
Get your endpoint, then paste it — add your endpoint to your client
USE CASES
01
Answering a question about the data in the project
Find the bucket and table, then run SQL straight against the warehouse.
02
Building a transformation without writing the boilerplate
Describe what it should do, create it, run it, and read the job back.
03
Giving one agent read access and another full access
Set the allowed-tools or read-only header per connection instead of running two deployments.
04
Trying a change without touching production
Send the branch id so every operation in the session lands in a development branch.
05
Working on data before there is a Keboola project
Run in local mode against a directory of CSVs, with DuckDB doing the querying.
06
Iterating on a data app
Mint the repository credential, work on a draft, deploy it as a dev version, then delete the draft once it is promoted.
07
Running a component locally before wiring it into a pipeline
Clone and build it once, then run it against your local data.
26 tools
Listed in project docs. Your client may show a different list.
get_tablesquery_datasearchget_project_infoget_configscreate_configmodify_data_appget_data_appsdeploy_data_appmodify_python_js_data_appcreate_python_js_data_app_git_credentialdelete_python_js_data_app_draftrun_jobget_joblist_jobscreate_flowupdate_flowcreate_conditional_flowcreate_sql_transformationupdate_sql_transformationcreate_oauth_urlfind_component_idget_config_examplesget_accessible_projectsset_project_scopeBEFORE YOU INSTALL
What to know first
Tools you get
26 tools named in the project's documentation.
Requires
- A Keboola account and project
- uvx on PATH (local server)
- KBC_STORAGE_API_URL — your region's connection URL
INSTALLATION
Connect your client
MCP Clients
Claude Code
CLAUDE CODE · TERMINAL
claude mcp add --transport http keboola https://mcp.<YOUR_REGION>.keboola.com/mcpClaude Desktop
Log in once in a terminal so a session is stored (the client starts the server in the background, where a browser can't open):
CLAUDE DESKTOP · TERMINAL
uvx keboola_mcp_server login --api-url https://connection.<YOUR_REGION>.keboola.comThen add this to claude_desktop_config.json (Settings → Developer → Edit Config) and restart Claude Desktop:
CLAUDE DESKTOP · JSON
{
"mcpServers": {
"keboola": {
"command": "uvx",
"args": [
"keboola_mcp_server"
],
"env": {
"KBC_STORAGE_API_URL": "https://connection.<YOUR_REGION>.keboola.com"
}
}
}
}<YOUR_REGION> is your Keboola stack's region in both the login command and the block. stdio is the default transport, so no --transport argument is needed. To work in a development branch, add "KBC_BRANCH_ID": "<branch id>" to env.
Cursor
Log in once in a terminal so a session is stored:
CURSOR · TERMINAL
uvx keboola_mcp_server login --api-url https://connection.<YOUR_REGION>.keboola.comThen in Cursor go to Settings → MCP → + Add new global MCP Server and use:
CURSOR · JSON
{
"mcpServers": {
"keboola": {
"command": "uvx",
"args": [
"keboola_mcp_server"
],
"env": {
"KBC_STORAGE_API_URL": "https://connection.<YOUR_REGION>.keboola.com"
}
}
}
}<YOUR_REGION> is your Keboola stack's region in both the login command and the block. stdio is the default transport, so no --transport argument is needed. To work in a development branch, add "KBC_BRANCH_ID": "<branch id>" to env.
Cursor — WSL
Log in once inside WSL so a session is stored:
CURSOR — WSL · TERMINAL
/snap/bin/uvx keboola_mcp_server login --api-url https://connection.<YOUR_REGION>.keboola.comThen use this configuration in Cursor:
CURSOR — WSL · JSON
{
"mcpServers": {
"keboola": {
"command": "wsl.exe",
"args": [
"bash",
"-c",
"export KBC_STORAGE_API_URL=https://connection.<YOUR_REGION>.keboola.com && /snap/bin/uvx keboola_mcp_server"
]
}
}
}The whole bash -c script is a single argument. <YOUR_REGION> is your Keboola stack's region in both the login command and the block.
Docker
A container can't open a browser, so it authenticates with a Keboola access token and project ID:
DOCKER · TERMINAL
docker pull keboola/mcp-server:latest
docker run --name keboola_mcp_server --rm -it -p 127.0.0.1:8000:8000 -e KBC_STORAGE_API_URL="https://connection.<YOUR_REGION>.keboola.com" -e KBC_STORAGE_TOKEN="<YOUR_KBC_STORAGE_TOKEN>" -e KBC_PROJECT_ID="<YOUR_KBC_PROJECT_ID>" keboola/mcp-server:latest --transport streamable-http --host 0.0.0.0The server then listens for Streamable HTTP connections at http://localhost:8000/mcp — point your client there.
