The Keboola Explorer MCP Server enables AI agents to seamlessly interact with Keboola projects, providing a bridge for data management and analysis capabilities:
Storage Management: List and retrieve information about buckets and tables, including metadata and column details, and update descriptions
SQL Operations: Execute SELECT queries against data, create and update SQL transformations
Component Management: List available components (extractors, writers, applications) and access their configurations
Job Control: List, filter, and trigger component or transformation jobs
Metadata Access: Retrieve and update documentation/metadata for project elements
Data Exploration: Query and analyze data to enable exploration, analysis, and pipeline creation
Connects to Snowflake to provide access to Keboola data stored in Snowflake warehouses, enabling data exploration and preview capabilities.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Keboola Explorer MCP Server list all tables in the sales bucket"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
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.
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.
Related MCP server: Google BigQuery MCP Server by CData
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 Streamlit Data Apps displaying your queries over storage data.
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.
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.
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.
Get your remote server URL: Navigate to your Keboola Project Settings → MCP Server tab
Copy the server URL: It will look like https://mcp.<YOUR_REGION>.keboola.com/mcp
Configure your AI assistant: Paste the URL into your AI assistant's MCP settings
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")
Cursor: Use the "Install In Cursor" button in your project's MCP Server settings or click
this button
Claude Desktop: Add the integration via Settings → Integrations
Claude Code: Install using claude mcp add --transport http keboola <URL> (see below for details)
Windsurf: Configure with the remote server URL
Make: Configure with the remote server URL
Other MCP clients: Configure with the remote server URL
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 <YOUR_REGION> with your Keboola region:
claude mcp add --transport http keboola https://mcp.<YOUR_REGION>.keboola.com/mcpRegion-specific commands:
Region | Installation Command |
US Virginia AWS |
|
US Virginia GCP |
|
EU Frankfurt AWS |
|
EU Ireland Azure |
|
EU Frankfurt GCP |
|
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:
Log in with your Keboola account
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.
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: <branchId>, otherwise the MCP Server uses production branch as default. This should be managed by the AI client or the environment handling the server connection.
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.
Header | Description | Example |
| Comma-separated list of allowed tools |
|
| Comma-separated list of tools to exclude |
|
| Restrict to read-only tools only |
|
Filters apply in order: allowed → read-only intersection → disallowed exclusion. Empty headers = no restriction.
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.
X-Read-Only-Mode: trueFor detailed documentation, see developers.keboola.com/integrate/mcp/#tool-authorization-and-access-control.
Run the MCP server on your own machine for full control and easy development. Choose this when you want to customize tools, debug locally, or iterate quickly. You’ll install the server, authenticate (a one-time browser login — no token to paste), and start it. This approach offers maximum flexibility (custom tools, local logging, offline iteration) but requires manual setup and you manage updates and secrets yourself.
The server supports multiple transport options, which can be selected by providing the --transport <transport> argument when starting the server:
stdio - Default when --transport is not specified. Standard input/output, typically used for local deployment with a single client.
streamable-http - Runs the server remotely over HTTP with a bidirectional streaming channel, allowing the client and server to continuously exchange messages. Connect via /mcp (e.g., http://localhost:8000/mcp).
http-compat - An alias for streamable-http, kept for backwards compatibility.
To work with your Keboola project the server needs two things: your Keboola Region (KBC_STORAGE_API_URL) and a way to authenticate. The recommended way is a one-time browser login — you never create, copy, or paste a token. Optionally set KBC_BRANCH_ID to work inside a development branch.
Some of the variables are not taken from the request headers:
KBC_STORAGE_API_URL: a server that was started with its own Storage API URL (the --api-url parameter or the KBC_STORAGE_API_URL environment variable) only serves that one Keboola stack. An X-Storage-Api-Url header asking for a different host is ignored (a warning is logged) — the server keeps its own URL for the request. Start the server without a Storage API URL of its own if you want each request to choose its stack.
KBC_KUBERNETES_TOKEN_PATH (deployed servers only, see docs/kubernetes-sa-auth.md): read from the environment only, never from a header.
KBC_WORKSPACE_ID / KBC_WORKSPACE_SCHEMA: same idea as the Storage API URL above — a server started with its own workspace pin (via either variable, or --workspace-id) keeps that pin for every request; an X-Workspace-Id or X-Workspace-Schema header asking for a different workspace is ignored (a warning is logged). A server with no pin of its own (the shared multi-user case) keeps taking the pin from the request, per-request, as described below.
Sign in once with your browser; the server stores the session and refreshes it automatically, so there are no tokens to manage:
uvx keboola_mcp_server login --api-url https://connection.YOUR_REGION.keboola.comThis opens your browser to sign in to Keboola, then saves the stack-wide session to ~/.keboola/mcp/credentials.json (readable only by you, one entry per stack). Afterwards, start the server with only KBC_STORAGE_API_URL set — no token required. Which project(s) to work on is chosen afterwards, in the conversation (get_accessible_projects / set_project_scope), not during login.
Command | What it does |
| Sign in to a stack |
| Sign in again / switch account |
| Print the current session token (debugging) |
| Remove the stored session for a stack (or all stacks) |
When you start the server over stdio in an interactive terminal with no stored session, it runs this browser login automatically on first start. MCP clients (Claude, Cursor, …) launch the server in the background where a browser can't open, so run login once yourself first.
For containers or CI where a browser login isn't possible, provide a Keboola access or personal access token directly — set KBC_STORAGE_TOKEN (env var) or send the X-StorageAPI-Token header — together with KBC_PROJECT_ID (or the X-KBC-ProjectId header) to select the project. On HTTP transports these can be supplied per request as headers, so each request carries its own credentials.
Pins queries to one specific, already-existing workspace by its ID instead of the schema-based lookup above, and takes precedence over KBC_WORKSPACE_SCHEMA when both are set. This is the option a Data App / kai-agent caller supplies, as the X-Workspace-Id header, so that Kai embedded in that app queries only through its own workspace.
Set via the KBC_WORKSPACE_ID environment variable, the --workspace-id CLI flag, or (per-request, for multi-user deployments) the X-Workspace-Id header.
Your Keboola Region API URL depends on your deployment region. You can determine your region by looking at the URL in your browser when logged into your Keboola project:
Region | API URL |
AWS North America |
|
AWS Europe |
|
Google Cloud EU |
|
Google Cloud US |
|
Azure EU |
|
To operate on a specific Keboola development branch, set the branch ID using the KBC_BRANCH_ID parameter. The MCP server scopes its functionality to the specified branch, ensuring all changes remain isolated and do not impact the production branch.
If not provided, the server uses the production branch by default.
For development work, set KBC_BRANCH_ID to the numeric ID of your branch (e.g., 123456). 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.
On remote transports, you can override per-request with the HTTP header X-Branch-Id: <branchId> or KBC_BRANCH_ID: <branchId>.
Make sure you have:
Python 3.10+ installed
Access to a Keboola project with admin rights
Your preferred MCP client (Claude, Cursor, etc.)
Note: Make sure you have uv installed. The MCP client will use it to automatically download and run the Keboola MCP Server.
Installing uv:
macOS/Linux:
#if homebrew is not installed on your machine use:
# /bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"
# Install using Homebrew
brew install uvWindows:
# Using the installer script
powershell -ExecutionPolicy ByPass -c "irm https://astral.sh/uv/install.ps1 | iex"
# Or using pip
pip install uv
# Or using winget
winget install --id=astral-sh.uv -eFor more installation options, see the official uv documentation.
There are four ways to use the Keboola MCP Server, depending on your needs:
In this mode, Claude or Cursor automatically starts the MCP server for you.
Log in once in a terminal so a session is stored (the client launches the server in the background, where a browser can't open):
uvx keboola_mcp_server login --api-url https://connection.YOUR_REGION.keboola.comConfigure your MCP client (Claude/Cursor) with the settings below — only KBC_STORAGE_API_URL is needed.
The client will automatically launch the MCP server when needed.
Go to Claude (top left corner of your screen) -> Settings → Developer → Edit Config (if you don't see the claude_desktop_config.json, create it)
Add the following configuration:
Restart Claude desktop for changes to take effect
{
"mcpServers": {
"keboola": {
"command": "uvx",
"args": ["keboola_mcp_server --transport <transport>"],
"env": {
"KBC_STORAGE_API_URL": "https://connection.YOUR_REGION.keboola.com",
"KBC_BRANCH_ID": "your_branch_id_optional"
}
}
}
}Config file locations:
macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Windows: %APPDATA%\Claude\claude_desktop_config.json
Go to Settings → MCP
Click "+ Add new global MCP Server"
Configure with these settings:
{
"mcpServers": {
"keboola": {
"command": "uvx",
"args": ["keboola_mcp_server --transport <transport>"],
"env": {
"KBC_STORAGE_API_URL": "https://connection.YOUR_REGION.keboola.com",
"KBC_BRANCH_ID": "your_branch_id_optional"
}
}
}
}Note: Use short, descriptive names for MCP servers. Since the full tool name includes the server name and must stay under ~60 characters, longer names may be filtered out in Cursor and will not be displayed to the Agent.
When running the MCP server from Windows Subsystem for Linux with Cursor AI, use this configuration:
{
"mcpServers": {
"keboola":{
"command": "wsl.exe",
"args": [
"bash",
"-c '",
"export KBC_STORAGE_API_URL=https://connection.YOUR_REGION.keboola.com &&",
"export KBC_BRANCH_ID=your_branch_id_optional &&",
"/snap/bin/uvx keboola_mcp_server --transport <transport>",
"'"
]
}
}
}For developers working on the MCP server code itself:
Clone the repository and set up a local environment
Configure Claude/Cursor to use your local Python path:
{
"mcpServers": {
"keboola": {
"command": "/absolute/path/to/.venv/bin/python",
"args": [
"-m",
"keboola_mcp_server --transport <transport>"
],
"env": {
"KBC_STORAGE_API_URL": "https://connection.YOUR_REGION.keboola.com",
"KBC_BRANCH_ID": "your_branch_id_optional"
}
}
}
}You can run the server manually in a terminal for testing or debugging:
# Sign in once (stores a session under ~/.keboola/mcp), then start the server.
export KBC_STORAGE_API_URL=https://connection.YOUR_REGION.keboola.com
uvx keboola_mcp_server login --api-url "$KBC_STORAGE_API_URL"
uvx keboola_mcp_server --transport streamable-httpNote: This mode is primarily for debugging or testing. For normal use with Claude or Cursor, you do not need to manually run the server.
Note: The server will use the Streamable HTTP transport and listen on
localhost:8000for incoming connections at/mcp. You can use--portand--hostparameters to make it listen elsewhere.
A container can't open a browser, so authenticate with a token (see Authenticating without a browser): set KBC_STORAGE_TOKEN to a Keboola access/personal access token and KBC_PROJECT_ID to the target project. (Over HTTP you can instead pass X-StorageAPI-Token / X-KBC-ProjectId headers per request and omit these.)
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_KEBOOLA_TOKEN" \
-e KBC_PROJECT_ID="YOUR_PROJECT_ID" \
-e KBC_BRANCH_ID="YOUR_BRANCH_ID_OPTIONAL" \
keboola/mcp-server:latest \
--transport streamable-http \
--host 0.0.0.0Note: The server will use the Streamable HTTP transport and listen on
localhost:8000for incoming connections at/mcp. You can change-pto map the container's port somewhere else.
Scenario | Need to Run Manually? | Use This Setup |
Using Claude/Cursor | No | Configure MCP in app settings |
Developing MCP locally | No (Claude starts it) | Point config to python path |
Testing CLI manually | Yes | Use terminal to run |
Using Docker | Yes | Run docker container |
Once your MCP client (Claude/Cursor) is configured and running, you can start querying your Keboola data:
You can start with a simple query to confirm everything is working:
What buckets and tables are in my Keboola project?Data Exploration:
"What tables contain customer information?"
"Run a query to find the top 10 customers by revenue"
Data Analysis:
"Analyze my sales data by region for the last quarter"
"Find correlations between customer age and purchase frequency"
Data Pipelines:
"Create a SQL transformation that joins customer and order tables"
"Start the data extraction job for my Salesforce component"
MCP Client | Support Status | Connection Method |
Claude (Desktop & Web) | ✅ supported | stdio |
Cursor | ✅ supported | stdio |
Windsurf, Zed, Replit | ✅ Supported | stdio |
Codeium, Sourcegraph | ✅ Supported | Streamable HTTP |
Custom MCP Clients | ✅ Supported | Streamable HTTP or stdio |
Note: Your AI agents will automatically adjust to new tools.
For a complete list of available tools with detailed descriptions, parameters, and usage examples, see TOOLS.md.
Issue | Solution |
Authentication Errors | Re-run |
Connection Timeout | Check network connectivity |
Basic setup:
uv sync --extra devWith the basic setup, you can use uv run tox to run tests and check code style.
Recommended setup:
uv sync --extra dev --extra tests --extra integtests --extra codestyleWith the recommended setup, packages for testing and code style checking will be installed which allows IDEs like VsCode or Cursor to check the code or run tests during development.
To run integration tests locally, use uv run tox -e integtests.
NOTE: You will need to set the following environment variables:
INTEGTEST_POOL_STORAGE_API_URL
INTEGTEST_STORAGE_TOKENS
INTEGTEST_STORAGE_TOKEN_STORAGE_BRANCHES
In order to get these values, you need dedicated Keboola projects for integration tests.
Each test session creates its own read-only workspace, so no workspace schema needs to be
configured. See integtests/README.md for detailed setup instructions and design documentation.
uv.lockUpdate the uv.lock file if you have added or removed dependencies. Also consider updating the lock with newer dependency
versions when creating a release (uv lock --upgrade).
When you make changes to any tool descriptions (docstrings in tool functions), you must regenerate the TOOLS.md documentation file to reflect these changes:
uv run python -m src.keboola_mcp_server.generate_tool_docsWe do not cut a release for every merged PR. Work lands on the trunk (main)
continuously, and we release periodically once changes have been re-tested together —
this avoids breaking working setups for users.
A release is made by pushing one or two git tags:
vX.Y.Z — the MCP server release (always)
agent-vX.Y.Z — the In Platform Agent release (only when the agent is being released too)
Either tag triggers release.yml CI, which builds and publishes the Docker image. KaiBench
runs only on production vX.Y.Z tags (not agent-vX.Y.Z, and not -dev. prereleases). Use
the release-notes skill — it prepares the release notes and draft PR and walks through
tagging both vX.Y.Z and agent-vX.Y.Z.
⭐ The primary way to get help, report bugs, or request features is by opening an issue on GitHub. ⭐
The development team actively monitors issues and will respond as quickly as possible. For general information about Keboola, please use the resources below.
Issue Tracker ← Primary contact method for MCP Server
Get detailed information about a specific bucket.
| Name | Required | Description | Default |
|---|---|---|---|
| bucket_id | Yes | Unique ID of the bucket. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the action but doesn't cover critical aspects like whether this is a read-only operation, potential rate limits, authentication needs, error handling, or what 'detailed information' entails. This leaves significant gaps for a tool that likely interacts with storage systems.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without unnecessary words. It's front-loaded and wastes no space, making it easy for an agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description is incomplete. It doesn't explain what 'detailed information' includes, potential return formats, or behavioral traits like safety and performance. For a tool that likely provides metadata, more context is needed to guide effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with the single parameter 'bucket_id' clearly documented. The description adds no additional meaning beyond the schema, such as format examples or constraints, but since the schema is comprehensive, a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and the resource 'detailed information about a specific bucket', making the purpose understandable. However, it doesn't differentiate from sibling tools like 'list_bucket_info' or 'get_table_metadata', which likely serve related but distinct purposes, preventing a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With siblings such as 'list_bucket_info' and 'get_table_metadata' available, there's no indication of context, prerequisites, or exclusions, leaving the agent to guess based on names alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get detailed information about a specific table including its DB identifier and column information.
| Name | Required | Description | Default |
|---|---|---|---|
| table_id | Yes | Unique ID of the table. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool retrieves 'detailed information' but doesn't specify behavioral traits like whether it's read-only, requires specific permissions, has rate limits, or what happens if the table doesn't exist. This is a significant gap for a tool with no annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose. It avoids unnecessary words, though it could be slightly more structured by explicitly separating the tool's action from the information retrieved.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (retrieving metadata for a specific table), no annotations, no output schema, and 100% schema coverage, the description is minimally adequate. It covers the basic purpose but lacks details on usage context, behavioral traits, and output format, leaving gaps in completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, with the single parameter 'table_id' documented as 'Unique ID of the table.' The description adds no additional meaning beyond what the schema provides, such as format examples or constraints. With high schema coverage, the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb ('Get detailed information') and resource ('about a specific table'), including what information is retrieved ('DB identifier and column information'). However, it doesn't explicitly differentiate from sibling tools like 'list_bucket_tables' or 'query_table', which prevents a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, when not to use it, or how it differs from sibling tools such as 'list_bucket_tables' (which might list tables) or 'query_table' (which might query table data).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List information about all buckets in the project.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the action ('List information') but doesn't describe what 'information' includes, whether it's paginated, requires specific permissions, or has rate limits. This is a significant gap for a tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without any fluff or redundancy. It's appropriately sized and front-loaded, making it easy for an agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description is incomplete. It doesn't specify what 'information' is returned, how results are formatted, or any behavioral traits like error handling. For a tool with no structured data support, this leaves too many unknowns for reliable agent use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters, and schema description coverage is 100%, so there's no need for parameter details in the description. The baseline for 0 parameters is 4, as the description doesn't need to compensate for any schema gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('List') and resource ('information about all buckets in the project'), making the purpose immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'get_bucket_metadata' or 'list_bucket_tables', which might offer overlapping functionality.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'get_bucket_metadata' or 'list_bucket_tables'. There's no mention of prerequisites, context, or exclusions, leaving the agent to infer usage based on tool names alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all tables in a specific bucket with their basic information.
| Name | Required | Description | Default |
|---|---|---|---|
| bucket_id | Yes | Unique ID of the bucket. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states this is a list operation but doesn't mention whether it's paginated, rate-limited, requires specific permissions, or what format the 'basic information' returns. For a tool with zero annotation coverage, this leaves significant behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that gets straight to the point with no wasted words. It's appropriately sized for a simple list operation, though it could be slightly more front-loaded with key behavioral details given the lack of annotations.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description is incomplete. It doesn't explain what 'basic information' includes, how results are structured, or any behavioral constraints. For a tool that presumably returns multiple items, this leaves the agent with insufficient context for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the input schema already documents the single 'bucket_id' parameter thoroughly. The description adds no additional parameter semantics beyond what's in the schema, meeting the baseline expectation when schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('List all tables') and target resource ('in a specific bucket'), providing a specific verb+resource combination. However, it doesn't distinguish this tool from sibling tools like 'list_bucket_info' or 'get_table_metadata', which might offer similar or overlapping functionality.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'list_bucket_info' or 'query_table'. It mentions 'basic information' but doesn't clarify what that includes or exclude compared to other tools, leaving the agent to guess about appropriate usage contexts.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all configurations for a specific component.
| Name | Required | Description | Default |
|---|---|---|---|
| component_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. While 'List all configurations' implies a read operation, it doesn't address important behavioral aspects like pagination, rate limits, authentication requirements, error conditions, or what format the configurations are returned in. The description is minimal and lacks operational context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise - a single sentence that gets straight to the point with zero wasted words. It's appropriately sized for a simple listing tool and front-loads the essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no annotations, no output schema, and 0% schema description coverage, the description is inadequate. It doesn't explain what 'configurations' means in this context, what format they're returned in, whether there are limitations on what can be listed, or provide any operational context. The minimal description leaves too many questions unanswered.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage and 1 undocumented parameter, the description provides no additional semantic information about the 'component_id' parameter. It doesn't explain what constitutes a valid component ID, where to find component IDs, or provide any examples or constraints beyond what's minimally implied by the parameter name.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('List all configurations') and the target resource ('for a specific component'), providing a specific verb+resource combination. However, it doesn't differentiate this tool from its sibling 'list_components', which appears to list components rather than their configurations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. There's no mention of prerequisites, when-not-to-use scenarios, or how this differs from sibling tools like 'list_components' or other metadata tools on the server.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all available components and their configurations.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the action ('List all available components and their configurations') but doesn't reveal critical traits like whether this is a read-only operation, potential rate limits, authentication needs, or what the output format entails. This leaves significant gaps for a tool with no structured safety hints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core action ('List all available components and their configurations') with zero waste. Every word serves a purpose, making it highly concise and well-structured for quick comprehension.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (0 parameters, no output schema, no annotations), the description is adequate as a basic overview. However, it lacks details on output format, behavioral constraints, and differentiation from siblings, which could be important for an agent to use it correctly in context with other tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters, and the schema description coverage is 100%, so there are no parameters to document. The description appropriately doesn't add unnecessary param details, earning a high baseline score for not overcomplicating a parameterless tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('List') and resource ('components and their configurations'), making the purpose immediately understandable. However, it doesn't distinguish this tool from its sibling 'list_component_configs', which appears to serve a similar function, preventing a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'list_component_configs' or other sibling tools. It lacks context about prerequisites, timing, or any explicit when/when-not instructions, leaving the agent with minimal usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Executes an SQL SELECT query to get the data from the underlying snowflake database.
* When constructing the SQL SELECT query make sure to use the fully qualified table names
that include the database name, schema name and the table name.
* The fully qualified table name can be found in the table information, use a tool to get the information
about tables. The fully qualified table name can be found in the response for that tool.
* Snowflake is case-sensitive so always wrap the column names in double quotes.
Examples:
* SQL queries must include the fully qualified table names including the database name, e.g.:
SELECT * FROM "db_name"."db_schema_name"."table_name";
| Name | Required | Description | Default |
|---|---|---|---|
| sql_query | Yes | SQL SELECT query to run. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It does well by specifying that this is for SQL SELECT queries only (implying read-only operations), mentioning Snowflake's case-sensitivity requirements, and providing implementation guidance about fully qualified table names. However, it doesn't address potential limitations like query timeouts, result size limits, or authentication requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and efficiently organized. It starts with the core purpose, then provides bulleted implementation guidance, and concludes with concrete examples. Every sentence serves a clear purpose without redundancy, making it easy for an AI agent to parse and apply the information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no annotations and no output schema, the description provides reasonable coverage of the execution behavior and requirements. However, it doesn't describe what the output looks like (result format, error responses), which is a significant gap given the absence of output schema. The description adequately covers the input requirements but leaves the output behavior unspecified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage for the single parameter 'sql_query', the schema already documents this parameter adequately. The description adds some value by providing examples and formatting requirements (double quotes, fully qualified names), but doesn't significantly enhance the parameter understanding beyond what the schema provides. This meets the baseline expectation for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool 'executes an SQL SELECT query to get the data from the underlying snowflake database', which specifies the verb (executes), resource (SQL SELECT query), and target system (Snowflake database). However, it doesn't explicitly differentiate from sibling tools like get_table_metadata or list_bucket_tables, which appear to be metadata-focused rather than data retrieval tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context about when to use this tool - for executing SQL SELECT queries against Snowflake databases. It mentions prerequisites like using fully qualified table names and referencing table information from other tools, but doesn't explicitly state when NOT to use it or name specific alternatives among the sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v1.0.0get_bucket_metadataget_table_metadatalist_bucket_infolist_bucket_tableslist_component_configslist_componentsquery_tableEach tool has a clearly distinct purpose with no overlap: get_bucket_metadata vs list_bucket_info (detail vs list), get_table_metadata vs query_table (metadata vs data retrieval), and list_bucket_tables vs list_components (bucket-specific vs component-focused). The descriptions reinforce these distinctions, making misselection unlikely.
All tools follow a consistent verb_noun pattern with snake_case: get_*, list_*, and query_* are used predictably throughout. The naming is uniform and readable, with no deviations in style or convention.
With 7 tools, the count is well-scoped for a Keboola Explorer server focused on metadata retrieval and data querying. Each tool earns its place, covering buckets, tables, components, and queries without being overwhelming or too sparse.
The tool set provides strong coverage for exploration and querying in Keboola, with metadata listing and retrieval for buckets, tables, and components, plus data querying. A minor gap exists in write operations (e.g., creating or modifying resources), but agents can effectively navigate and query the environment with the available tools.
MCP server unifying ERPs, CRMs, APIs and knowledge base for Claude, ChatGPT and Gemini.
Hosted Amazon Seller Central and Amazon Ads MCP server for Claude, ChatGPT, Cursor, and agents.
Hosted MCP server connecting claude.ai, ChatGPT and other AI apps to your own computer
An MCP server that provides read access to your cloud storage providers, bank accounts and more.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/keboola/mcp-server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
