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.
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.
- 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
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.
One command plus a key — uvx keboola_mcp_server --transport streamable-http, then supply credentials