mcp-clickhouse
Execute SQL queries on ClickHouse clusters, list databases and tables with enhanced filtering capabilities using LIKE/NOT LIKE patterns.
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., "@mcp-clickhouselist tables in my_db matching user_% or order_%"
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.
ClickHouse MCP Server (Enhanced)
An MCP server for ClickHouse with enhanced filtering capabilities for database and table discovery.
Note: This is a fork of ClickHouse/mcp-clickhouse with added filtering support for
list_databasesandlist_tablestools. Both functions now support single or multiple LIKE/NOT LIKE patterns for flexible database and table discovery.
What's New in This Fork
✨ Multiple Pattern Support: Filter databases and tables using multiple LIKE patterns with OR logic
✨ Advanced Exclusions: Exclude using multiple NOT LIKE patterns with AND logic
✨ Backward Compatible: Single string patterns still work exactly as before
✨ Pagination Aware: Multiple patterns work seamlessly with table pagination
Related MCP server: clickhouse-mcp-server
Features
ClickHouse Tools
run_select_queryExecute SQL queries on your ClickHouse cluster.
Input:
sql(string): The SQL query to execute.All ClickHouse queries are run with
readonly = 1to ensure they are safe.
list_databasesList databases on your ClickHouse cluster.
Optional inputs:
like(string or list of strings): ApplyLIKEfilter(s) to database names. Multiple patterns are combined with OR logic.not_like(string or list of strings): ApplyNOT LIKEfilter(s) to exclude database names. Multiple patterns are combined with AND logic.
Examples:
like="prod_%"- Single patternlike=["prod_%", "staging_%"]- Multiple patterns (matches either)not_like=["test_%", "temp_%"]- Exclude multiple patterns (excludes both)
list_tablesList tables in a database with pagination.
Required input:
database(string).Optional inputs:
like(string or list of strings): ApplyLIKEfilter(s) to table names. Multiple patterns are combined with OR logic.not_like(string or list of strings): ApplyNOT LIKEfilter(s) to exclude table names. Multiple patterns are combined with AND logic.page_token(string): Token returned by a previous call for fetching the next page.page_size(int, default50): Number of tables returned per page.include_detailed_columns(bool, defaulttrue): Whenfalse, omits column metadata for lighter responses while keeping the fullcreate_table_query.
Examples:
like="user_%"- Single patternlike=["user_%", "order_%"]- Multiple patterns (matches either)not_like=["temp_%", "backup_%"]- Exclude multiple patterns (excludes both)
Response shape:
tables: Array of table objects for the current page.next_page_token: Pass this value back to fetch the next page, ornullwhen there are no more tables.total_tables: Total count of tables that match the supplied filters.
chDB Tools
run_chdb_select_queryExecute SQL queries using chDB's embedded ClickHouse engine.
Input:
sql(string): The SQL query to execute.Query data directly from various sources (files, URLs, databases) without ETL processes.
Enhanced Filtering Capabilities
This fork adds powerful filtering capabilities to both list_databases and list_tables tools, allowing you to efficiently discover and filter databases and tables using SQL LIKE patterns.
Key Features
Single Pattern Filtering
Filter with a single LIKE pattern:
like="prod_%"matches all databases/tables starting with "prod_"Exclude with a single NOT LIKE pattern:
not_like="test_%"excludes all starting with "test_"
Multiple Pattern Filtering
OR logic for
like:like=["user_%", "order_%"]matches tables starting with "user_" OR "order_"AND logic for
not_like:not_like=["temp_%", "backup_%"]excludes tables starting with "temp_" AND tables starting with "backup_"
Combined Filtering
Mix both:
like=["prod_%", "staging_%"], not_like=["_backup"]includes prod/staging but excludes any ending with "_backup"
Use Cases
Scenario 1: Multi-environment Database Discovery
# Find all production and staging databases
list_databases(like=["prod_%", "staging_%"])Scenario 2: Clean Table Listing
# List all user and order tables, but exclude temporary and backup tables
list_tables(
database="mydb",
like=["user_%", "order_%"],
not_like=["temp_%", "backup_%"]
)Scenario 3: Development Environment Cleanup
# Find all test/temp/dev databases for cleanup
list_databases(like=["test_%", "temp_%", "dev_%"])Health Check Endpoint
When running with HTTP or SSE transport, a health check endpoint is available at /health. This endpoint:
Returns
200 OKwith the ClickHouse version if the server is healthy and can connect to ClickHouseReturns
503 Service Unavailableif the server cannot connect to ClickHouse
Example:
curl http://localhost:8000/health
# Response: OK - Connected to ClickHouse 24.3.1Configuration
This MCP server supports both ClickHouse and chDB. You can enable either or both depending on your needs.
Open the Claude Desktop configuration file located at:
On macOS:
~/Library/Application Support/Claude/claude_desktop_config.jsonOn Windows:
%APPDATA%/Claude/claude_desktop_config.json
Add the following:
{
"mcpServers": {
"mcp-clickhouse": {
"command": "uv",
"args": [
"run",
"--with",
"mcp-clickhouse-like",
"--python",
"3.10",
"mcp-clickhouse"
],
"env": {
"CLICKHOUSE_HOST": "<clickhouse-host>",
"CLICKHOUSE_PORT": "<clickhouse-port>",
"CLICKHOUSE_USER": "<clickhouse-user>",
"CLICKHOUSE_PASSWORD": "<clickhouse-password>",
"CLICKHOUSE_ROLE": "<clickhouse-role>",
"CLICKHOUSE_SECURE": "true",
"CLICKHOUSE_VERIFY": "true",
"CLICKHOUSE_CONNECT_TIMEOUT": "30",
"CLICKHOUSE_SEND_RECEIVE_TIMEOUT": "30"
}
}
}
}Update the environment variables to point to your own ClickHouse service.
Or, if you'd like to try it out with the ClickHouse SQL Playground, you can use the following config:
{
"mcpServers": {
"mcp-clickhouse": {
"command": "uv",
"args": [
"run",
"--with",
"mcp-clickhouse-like",
"--python",
"3.10",
"mcp-clickhouse"
],
"env": {
"CLICKHOUSE_HOST": "sql-clickhouse.clickhouse.com",
"CLICKHOUSE_PORT": "8443",
"CLICKHOUSE_USER": "demo",
"CLICKHOUSE_PASSWORD": "",
"CLICKHOUSE_SECURE": "true",
"CLICKHOUSE_VERIFY": "true",
"CLICKHOUSE_CONNECT_TIMEOUT": "30",
"CLICKHOUSE_SEND_RECEIVE_TIMEOUT": "30"
}
}
}
}For chDB (embedded ClickHouse engine), add the following configuration:
{
"mcpServers": {
"mcp-clickhouse": {
"command": "uv",
"args": [
"run",
"--with",
"mcp-clickhouse-like",
"--python",
"3.10",
"mcp-clickhouse"
],
"env": {
"CHDB_ENABLED": "true",
"CLICKHOUSE_ENABLED": "false",
"CHDB_DATA_PATH": "/path/to/chdb/data"
}
}
}
}You can also enable both ClickHouse and chDB simultaneously:
{
"mcpServers": {
"mcp-clickhouse": {
"command": "uv",
"args": [
"run",
"--with",
"mcp-clickhouse-like",
"--python",
"3.10",
"mcp-clickhouse"
],
"env": {
"CLICKHOUSE_HOST": "<clickhouse-host>",
"CLICKHOUSE_PORT": "<clickhouse-port>",
"CLICKHOUSE_USER": "<clickhouse-user>",
"CLICKHOUSE_PASSWORD": "<clickhouse-password>",
"CLICKHOUSE_SECURE": "true",
"CLICKHOUSE_VERIFY": "true",
"CLICKHOUSE_CONNECT_TIMEOUT": "30",
"CLICKHOUSE_SEND_RECEIVE_TIMEOUT": "30",
"CHDB_ENABLED": "true",
"CHDB_DATA_PATH": "/path/to/chdb/data"
}
}
}
}Locate the command entry for
uvand replace it with the absolute path to theuvexecutable. This ensures that the correct version ofuvis used when starting the server. On a mac, you can find this path usingwhich uv.Restart Claude Desktop to apply the changes.
Running Without uv (Using System Python)
If you prefer to use the system Python installation instead of uv, you can install the package from PyPI and run it directly:
Install the package using pip:
python3 -m pip install mcp-clickhouse-likeTo upgrade to the latest version:
python3 -m pip install --upgrade mcp-clickhouse-likeOptional chDB Support: If you want to use chDB features (embedded ClickHouse engine), install with the chdb extra:
python3 -m pip install mcp-clickhouse-like[chdb]Note: chDB is not available on Windows. If you're on Windows, use the standard ClickHouse tools instead.
Update your Claude Desktop configuration to use Python directly:
{
"mcpServers": {
"mcp-clickhouse": {
"command": "python3",
"args": [
"-m",
"mcp_clickhouse.main"
],
"env": {
"CLICKHOUSE_HOST": "<clickhouse-host>",
"CLICKHOUSE_PORT": "<clickhouse-port>",
"CLICKHOUSE_USER": "<clickhouse-user>",
"CLICKHOUSE_PASSWORD": "<clickhouse-password>",
"CLICKHOUSE_SECURE": "true",
"CLICKHOUSE_VERIFY": "true",
"CLICKHOUSE_CONNECT_TIMEOUT": "30",
"CLICKHOUSE_SEND_RECEIVE_TIMEOUT": "30"
}
}
}
}Alternatively, you can use the installed script directly:
{
"mcpServers": {
"mcp-clickhouse": {
"command": "mcp-clickhouse",
"env": {
"CLICKHOUSE_HOST": "<clickhouse-host>",
"CLICKHOUSE_PORT": "<clickhouse-port>",
"CLICKHOUSE_USER": "<clickhouse-user>",
"CLICKHOUSE_PASSWORD": "<clickhouse-password>",
"CLICKHOUSE_SECURE": "true",
"CLICKHOUSE_VERIFY": "true",
"CLICKHOUSE_CONNECT_TIMEOUT": "30",
"CLICKHOUSE_SEND_RECEIVE_TIMEOUT": "30"
}
}
}
}Note: Make sure to use the full path to the Python executable or the mcp-clickhouse script if they are not in your system PATH. You can find the paths using:
which python3for the Python executablewhich mcp-clickhousefor the installed script
Development
In
test-servicesdirectory rundocker compose up -dto start the ClickHouse cluster.Add the following variables to a
.envfile in the root of the repository.
Note: The use of the default user in this context is intended solely for local development purposes.
CLICKHOUSE_HOST=localhost
CLICKHOUSE_PORT=8123
CLICKHOUSE_USER=default
CLICKHOUSE_PASSWORD=clickhouseRun
uv syncto install the dependencies. To installuvfollow the instructions here. Then dosource .venv/bin/activate.For easy testing with the MCP Inspector, run
fastmcp dev mcp_clickhouse/mcp_server.pyto start the MCP server.To test with HTTP transport and the health check endpoint:
# Using default port 8000 CLICKHOUSE_MCP_SERVER_TRANSPORT=http python -m mcp_clickhouse.main # Or with a custom port CLICKHOUSE_MCP_SERVER_TRANSPORT=http CLICKHOUSE_MCP_BIND_PORT=4200 python -m mcp_clickhouse.main # Then in another terminal: curl http://localhost:8000/health # or http://localhost:4200/health for custom port
Environment Variables
The following environment variables are used to configure the ClickHouse and chDB connections:
ClickHouse Variables
Required Variables
CLICKHOUSE_HOST: The hostname of your ClickHouse serverCLICKHOUSE_USER: The username for authenticationCLICKHOUSE_PASSWORD: The password for authentication
It is important to treat your MCP database user as you would any external client connecting to your database, granting only the minimum necessary privileges required for its operation. The use of default or administrative users should be strictly avoided at all times.
Optional Variables
CLICKHOUSE_PORT: The port number of your ClickHouse serverDefault:
8443if HTTPS is enabled,8123if disabledUsually doesn't need to be set unless using a non-standard port
CLICKHOUSE_ROLE: The role to use for authenticationDefault: None
Set this if your user requires a specific role
CLICKHOUSE_SECURE: Enable/disable HTTPS connectionDefault:
"true"Set to
"false"for non-secure connections
CLICKHOUSE_VERIFY: Enable/disable SSL certificate verificationDefault:
"true"Set to
"false"to disable certificate verification (not recommended for production)TLS certificates: The package uses your operating system trust store for TLS certificate verification via
truststore. We calltruststore.inject_into_ssl()at startup to ensure proper certificate handling. Python’s default SSL behavior is used as a fallback only if an unexpected error occurs.
CLICKHOUSE_CONNECT_TIMEOUT: Connection timeout in secondsDefault:
"30"Increase this value if you experience connection timeouts
CLICKHOUSE_SEND_RECEIVE_TIMEOUT: Send/receive timeout in secondsDefault:
"300"Increase this value for long-running queries
CLICKHOUSE_DATABASE: Default database to useDefault: None (uses server default)
Set this to automatically connect to a specific database
CLICKHOUSE_MCP_SERVER_TRANSPORT: Sets the transport method for the MCP server.Default:
"stdio"Valid options:
"stdio","http","sse". This is useful for local development with tools like MCP Inspector.
CLICKHOUSE_MCP_BIND_HOST: Host to bind the MCP server to when using HTTP or SSE transportDefault:
"127.0.0.1"Set to
"0.0.0.0"to bind to all network interfaces (useful for Docker or remote access)Only used when transport is
"http"or"sse"
CLICKHOUSE_MCP_BIND_PORT: Port to bind the MCP server to when using HTTP or SSE transportDefault:
"8000"Only used when transport is
"http"or"sse"
CLICKHOUSE_MCP_QUERY_TIMEOUT: Timeout in seconds for SELECT toolsDefault:
"30"Increase this if you see
Query timed out after ...errors for heavy queries
CLICKHOUSE_ENABLED: Enable/disable ClickHouse functionalityDefault:
"true"Set to
"false"to disable ClickHouse tools when using chDB only
chDB Variables
CHDB_ENABLED: Enable/disable chDB functionalityDefault:
"false"Set to
"true"to enable chDB tools
CHDB_DATA_PATH: The path to the chDB data directoryDefault:
":memory:"(in-memory database)Use
:memory:for in-memory databaseUse a file path for persistent storage (e.g.,
/path/to/chdb/data)
Example Configurations
For local development with Docker:
# Required variables
CLICKHOUSE_HOST=localhost
CLICKHOUSE_USER=default
CLICKHOUSE_PASSWORD=clickhouse
# Optional: Override defaults for local development
CLICKHOUSE_SECURE=false # Uses port 8123 automatically
CLICKHOUSE_VERIFY=falseFor ClickHouse Cloud:
# Required variables
CLICKHOUSE_HOST=your-instance.clickhouse.cloud
CLICKHOUSE_USER=default
CLICKHOUSE_PASSWORD=your-password
# Optional: These use secure defaults
# CLICKHOUSE_SECURE=true # Uses port 8443 automatically
# CLICKHOUSE_DATABASE=your_databaseFor ClickHouse SQL Playground:
CLICKHOUSE_HOST=sql-clickhouse.clickhouse.com
CLICKHOUSE_USER=demo
CLICKHOUSE_PASSWORD=
# Uses secure defaults (HTTPS on port 8443)For chDB only (in-memory):
# chDB configuration
CHDB_ENABLED=true
CLICKHOUSE_ENABLED=false
# CHDB_DATA_PATH defaults to :memory:For chDB with persistent storage:
# chDB configuration
CHDB_ENABLED=true
CLICKHOUSE_ENABLED=false
CHDB_DATA_PATH=/path/to/chdb/dataFor MCP Inspector or remote access with HTTP transport:
CLICKHOUSE_HOST=localhost
CLICKHOUSE_USER=default
CLICKHOUSE_PASSWORD=clickhouse
CLICKHOUSE_MCP_SERVER_TRANSPORT=http
CLICKHOUSE_MCP_BIND_HOST=0.0.0.0 # Bind to all interfaces
CLICKHOUSE_MCP_BIND_PORT=4200 # Custom port (default: 8000)When using HTTP transport, the server will run on the configured port (default 8000). For example, with the above configuration:
MCP endpoint:
http://localhost:4200/mcpHealth check:
http://localhost:4200/health
You can set these variables in your environment, in a .env file, or in the Claude Desktop configuration:
{
"mcpServers": {
"mcp-clickhouse": {
"command": "uv",
"args": [
"run",
"--with",
"mcp-clickhouse-like",
"--python",
"3.10",
"mcp-clickhouse"
],
"env": {
"CLICKHOUSE_HOST": "<clickhouse-host>",
"CLICKHOUSE_USER": "<clickhouse-user>",
"CLICKHOUSE_PASSWORD": "<clickhouse-password>",
"CLICKHOUSE_DATABASE": "<optional-database>",
"CLICKHOUSE_MCP_SERVER_TRANSPORT": "stdio",
"CLICKHOUSE_MCP_BIND_HOST": "127.0.0.1",
"CLICKHOUSE_MCP_BIND_PORT": "8000"
}
}
}
}Note: The bind host and port settings are only used when transport is set to "http" or "sse".
Running tests
uv sync --all-extras --dev # install dev dependencies
uv run ruff check . # run linting
docker compose up -d test_services # start ClickHouse
uv run pytest -v tests
uv run pytest -v tests/test_tool.py # ClickHouse only
uv run pytest -v tests/test_chdb_tool.py # chDB onlyComparison with Upstream
This fork maintains full compatibility with the upstream project while adding enhanced filtering capabilities:
Feature | Upstream | This Fork |
Single LIKE pattern | ✅ | ✅ |
Single NOT LIKE pattern | ✅ | ✅ |
Multiple LIKE patterns | ❌ | ✅ (OR logic) |
Multiple NOT LIKE patterns | ❌ | ✅ (AND logic) |
Pagination support | ✅ | ✅ (with patterns) |
Backward compatible | - | ✅ |
Implementation Details
Type Safety: Uses
Union[str, List[str]]for pattern parametersSQL Generation: Patterns are properly escaped using
format_query_value()to prevent SQL injectionPagination: Multiple patterns are stored in the pagination cache and validated across pages
Performance: Generates optimized SQL with parenthesized conditions for efficient query execution
YouTube Overview (Upstream Project)

Available Tools
3 toolslist_databasesA
List available ClickHouse databases
Args: like: Optional LIKE pattern(s) to filter database names. Can be a single string or list of strings. Multiple patterns are combined with OR logic. not_like: Optional NOT LIKE pattern(s) to exclude database names. Can be a single string or list of strings. Multiple patterns are combined with OR logic.
Returns: JSON array of database names
| Name | Required | Description | Default |
|---|---|---|---|
| like | No | ||
| not_like | No |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Describes parameters and return format but does not mention read-only nature or default behavior (all databases if no filters). Annotations absent, so burden is on description.
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?
Concise docstring format with Args and Returns sections; no unnecessary words, well-organized.
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?
Covers all parameters and return type; for a simple list tool with no output schema, it is sufficiently complete, though could mention default filtering behavior.
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?
Adds meaning beyond schema by explaining LIKE pattern logic, OR combination, and that patterns can be strings or lists; schema coverage is 0%, so description compensates well.
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 lists available ClickHouse databases, distinguishing it from siblings like list_tables and run_select_query.
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?
No explicit guidance on when to use versus alternatives, though the purpose is distinct enough; lacks when-not-to-use or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_tablesA
List available ClickHouse tables in a database, including schema, comment, row count, and column count.
Args: database: The database to list tables from like: Optional LIKE pattern(s) to filter table names. Can be a single string or list of strings. Multiple patterns are combined with OR logic. not_like: Optional NOT LIKE pattern(s) to exclude table names. Can be a single string or list of strings. Multiple patterns are combined with OR logic. page_token: Token for pagination, obtained from a previous call page_size: Number of tables to return per page (default: 50) include_detailed_columns: Whether to include detailed column metadata (default: True). When False, the columns array will be empty but create_table_query still contains all column information. This reduces payload size for large schemas.
Returns: A dictionary containing: - tables: List of table information (as dictionaries) - next_page_token: Token for the next page, or None if no more pages - total_tables: Total number of tables matching the filters
| Name | Required | Description | Default |
|---|---|---|---|
| database | Yes | ||
| like | No | ||
| not_like | No | ||
| page_token | No | ||
| page_size | No | ||
| include_detailed_columns | No |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses behavior: pagination, LIKE/not_like filtering, and the effect of 'include_detailed_columns' on payload. It also explains the output structure, making the tool's behavior transparent.
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 with clear sections for Args and Returns. It is somewhat long but each sentence adds value. It could be slightly more concise, but the structure aids readability.
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 complexity (6 parameters, no annotations, output schema exists), the description covers all necessary aspects: parameter explanations, return format, pagination, and filtering. It enables correct usage without needing additional context.
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 has 0% description coverage, but the description provides detailed explanations for all parameters, including their types, defaults, and behavior (e.g., multiple patterns with OR logic for like/not_like). This adds significant meaning beyond the bare schema.
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 the resource 'ClickHouse tables', and includes context like schema, comment, row count, and column count. It distinguishes from siblings 'list_databases' and 'run_select_query' which serve different purposes.
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 implicitly suggests using this tool for listing tables with filtering and pagination. It does not explicitly state when not to use or mention alternatives, but the sibling tool names and context make the usage clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
run_select_queryB
Run a SELECT query in a ClickHouse database
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description does not disclose read-only nature, potential performance impact, or required permissions. Only states the action.
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?
Single sentence is concise and front-loaded with action. However, extremely brief for a tool that executes arbitrary SQL; could include a brief note on safety.
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?
Simple tool, but missing details like result structure, error handling, and query restrictions. Adequate for minimal understanding but not robust.
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?
Parameter 'query' has no schema description. Description clarifies it is a SELECT query string, but does not specify format, length limits, or syntax expectations.
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?
Description explicitly states the action (run) and resource (SELECT query in ClickHouse database), distinguishing from sibling tools that list metadata.
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?
No guidance on when to use this tool versus alternatives like list_tables. Does not exclude non-SELECT queries or advise on appropriate contexts.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
TDQS
Each tool targets a distinct action: listing databases, listing tables, and running SELECT queries. No overlap in functionality.
All tools follow a consistent verb_noun pattern: list_databases, list_tables, run_select_query. No mixing of conventions.
With only 3 tools, the set is minimal for a database server but not excessively small; it covers basic browsing and querying.
The server lacks critical operations like creating or dropping databases/tables, inserting data, or describing schemas, leaving significant gaps for typical database interactions.
Maintenance
Resources
Unclaimed servers have limited discoverability.
Looking for Admin?
If you are the server author, to access and configure the admin panel.
Related MCP Connectors
MCP server for querying and analyzing data from ad platforms, analytics tools, and spreadsheets
Remote ChromaDB vector database MCP server with streamable HTTP transport
Related MCP Servers
- Apache 2.0
- AlicenseBqualityFmaintenanceAn MCP server implementation that enables Claude AI to interact with Clickhouse databases. Features include secure database connections, query execution, read-only mode support, and multi-query capabilities.22MIT
- FlicenseNot gradedqualityDmaintenanceA multi-database MCP server supporting PostgreSQL, ClickHouse, and MySQL that enables database exploration and SQL execution through MCP stdio or HTTP API.
- FlicenseAqualityCmaintenanceRead-only MCP server for ClickHouse that allows listing databases and tables, describing schemas, and running SELECT queries.4
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
MCP directory API
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/stiproot/mcp-clickhouse'
If you have feedback or need assistance with the MCP directory API, please join our Discord server