mcp-clickhouse
OfficialThis server allows you to interact with a ClickHouse database cluster through the following features:
Execute read-only SQL queries with
run_select_query, ensuring all queries are run withreadonly = 1List all databases on your ClickHouse cluster using
list_databasesList all tables within a specified database using
list_tables, with optional filtering usingLIKEsyntax
Connection details can be configured via environment variables or Claude Desktop configuration, including support for HTTPS, SSL verification, and timeouts.
Allows executing SQL queries on a ClickHouse cluster and retrieving information about databases and tables. It provides tools to run SELECT queries, list databases, and list tables in a database.
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-clickhouseshow me the top 10 customers by total sales this month"
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
An MCP server for ClickHouse.
The server implements MCP 2026-07-28 and supports legacy initialize handshakes from
2024-11-05 through 2025-11-25. Modern clients use sessionless requests and
server/discover. Existing clients can continue to negotiate the legacy protocol.
HTTP requests withoutMCP-Protocol-Version are routed through legacy handling so
clients from before 2025-06-18 can continue to connect. MCP 2026-07-28 permits
this behavior on servers that support those clients. Modern clients should send the
header on every POST request.
Features
ClickHouse Tools
ClickHouse tool responses are JSON-encoded strings. Integers outside
[-9007199254740991, 9007199254740991] are returned as decimal strings to preserve exact
values in JavaScript clients. This applies to query rows and integer table metadata. Safe-range
integers and booleans keep their JSON types.
run_queryExecute SQL queries on your ClickHouse cluster.
Input:
query(string): The SQL query to execute.Queries run in read-only mode by default (
CLICKHOUSE_ALLOW_WRITE_ACCESS=false), but writes can be enabled explicitly if needed.
list_databasesList all databases on your ClickHouse cluster.
list_tablesList tables in a database with pagination.
Required input:
database(string).Optional inputs:
like/not_like(string): ApplyLIKEorNOT LIKEfilters to table names.page_token(string): Single-use token returned by a previous call. It is retained for up to one hour.page_size(int, default50): Number of tables returned per page; must be greater than0.include_detailed_columns(bool, defaulttrue): Whenfalse, omits column metadata for lighter responses while keeping the fullcreate_table_query.
Response shape:
tables: Array of table objects for the current page.next_page_token: Pass this single-use value back before it expires 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:
query(string): The SQL query to execute.Integers outside
[-9007199254740991, 9007199254740991]are returned as decimal strings.Query data directly from various sources (files, URLs, databases) without ETL processes.
Requires the optional
chdbextra:pip install 'mcp-clickhouse[chdb]'
Health Check Endpoint
When running with HTTP or SSE transport, a health check endpoint is available at /health. This endpoint:
Returns
200 OK(body:OK) if the server is healthy and can connect to ClickHouseReturns
503 Service Unavailablewith a generic error message if the server cannot connect to ClickHouseReturns
503if a ClickHouse probe does not finish within two seconds. Concurrent requests share one in-flight probe
GET and HEAD requests to the endpoint are intentionally unauthenticated and exempt from Host and Origin validation so orchestrator probes (e.g. Kubernetes liveness/readiness, load balancers) can use runtime-assigned pod or target IPs without extra configuration. /health is reserved and cannot be used as the MCP transport path. The response body is deliberately minimal to avoid leaking backend version strings or error details; debug failures via the server logs.
Example:
curl http://localhost:8000/health
# Response: OKRelated MCP server: ClickHouse MCP Server
Security
Authentication for HTTP/SSE Transports
When using HTTP or SSE transport, authentication is required by default. The stdio transport (default) does not require authentication as it only communicates via standard input/output.
Three authentication modes are supported. Pick one:
Mode | When to use | Env var |
Static bearer token | Simple deployments, internal services |
|
OAuth / OIDC (via FastMCP) | Azure Entra, Google, GitHub, WorkOS, etc. |
|
Disabled | Local development only |
|
Startup fails if none of these are configured for HTTP/SSE transports.
Setting Up Authentication
Generate a secure token (can be any random string):
# Using uuidgen (macOS/Linux) uuidgen # Using openssl openssl rand -hex 32Configure the server with the token:
export CLICKHOUSE_MCP_AUTH_TOKEN="your-generated-token"Configure your MCP client to include the token in requests:
For Claude Desktop with HTTP/SSE transport:
{ "mcpServers": { "mcp-clickhouse": { "url": "http://127.0.0.1:8000", "headers": { "Authorization": "Bearer your-generated-token" } } } }Note: the
/healthendpoint is intentionally unauthenticated (see Health Check Endpoint above). To verify that bearer-token auth is actually rejecting unauthenticated requests, hit the MCP endpoint itself e.g. with the MCP Inspector, or by POSTing a JSON-RPC request to/mcpwith and without theAuthorizationheader and confirming the unauthenticated call returns401.
OAuth / OIDC via FastMCP
For production deployments with identity providers (Azure Entra, Google, GitHub, WorkOS, etc.), delegate authentication to FastMCP's built-in auth providers instead of using a static token. Set FASTMCP_SERVER_AUTH to the full class path of a FastMCP auth provider, along with the provider-specific FASTMCP_SERVER_AUTH_* variables, and leave CLICKHOUSE_MCP_AUTH_TOKEN unset.
Example (Azure Entra):
export FASTMCP_SERVER_AUTH=fastmcp.server.auth.providers.azure.AzureProvider
export FASTMCP_SERVER_AUTH_AZURE_TENANT_ID="<tenant-id>"
export FASTMCP_SERVER_AUTH_AZURE_CLIENT_ID="<client-id>"
export FASTMCP_SERVER_AUTH_AZURE_CLIENT_SECRET="<client-secret>"
export FASTMCP_SERVER_AUTH_AZURE_BASE_URL="https://mcp.example.com"
export FASTMCP_SERVER_AUTH_AZURE_REQUIRED_SCOPES="read access_as_user"mcp-clickhouse retains these FastMCP 2.14.7 environment prefixes for the FastMCP 4.0.0 built-in providers:
Provider class path | Provider variable prefix |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Append the uppercase provider field name to the prefix. See the FastMCP docs for each provider's configuration requirements.
Auth values set directly in the process environment take precedence case-insensitively.
The default .env load starts at the installed mcp_clickhouse package directory,
resolves symlinks first, and walks upward to the filesystem root. It loads the first
.env it finds and loads nothing if there is none. It never reads the working
directory, regardless of how the server is launched. A source checkout normally finds
the repository root .env. That file may also provide FASTMCP_SERVER_AUTH and its
provider fields. Its values take precedence over the explicit or compatibility auth
file.
For FastMCP 2 compatibility, mcp-clickhouse reads missing provider fields from .env
in the working directory, but that compatibility fallback cannot select
FASTMCP_SERVER_AUTH. A process-set FASTMCP_ENV_FILE replaces that compatibility
fallback and may provide both the selector and provider fields. Set it before startup.
The mcp-clickhouse compatibility loader reads only FASTMCP_SERVER_AUTH and
FASTMCP_SERVER_AUTH_* from that file, so it cannot inject CLICKHOUSE_* settings.
FastMCP 4 may use the same file for its own broader settings. A custom provider receives
no environment-derived constructor arguments and must support no-argument construction.
Treat both discovered and working-directory .env files as trusted authentication
configuration. Anyone who can create or write a .env in any directory from the package
directory up to the filesystem root can control which file is discovered, select the
provider, and set its fields. Anyone who can write the working-directory file controls every provider
field absent from the process and discovered configuration, including signing keys,
issuers and endpoints, and client secrets. A process-set FASTMCP_ENV_FILE that points
to an operator-owned file disables the working-directory fallback.
FastMCP 4 changed the default OAuth proxy client store. Deployments that relied on FastMCP 2's default OAuth proxy storage must have clients register and authorize again. Compatible custom storage, static bearer tokens, and JWT verification are unaffected.
Development Mode (Disabling Authentication)
For local development and testing only, you can disable authentication by setting:
export CLICKHOUSE_MCP_AUTH_DISABLED=true
export CLICKHOUSE_MCP_ALLOWED_HOSTS=127.0.0.1:8000,localhost:8000WARNING: Only use this for local development. Do not disable authentication when the server is exposed to any network.
Configuration
This MCP server supports both ClickHouse and chDB. You can enable either or both depending on your needs. Python 3.10 through 3.14 are supported. Python 3.12 is recommended for local launches.
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",
"--python",
"3.12",
"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"
}
}
}
}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",
"--python",
"3.12",
"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"
}
}
}
}For chDB (embedded ClickHouse engine), add the following configuration:
{
"mcpServers": {
"mcp-clickhouse": {
"command": "uv",
"args": [
"run",
"--with",
"mcp-clickhouse[chdb]",
"--python",
"3.12",
"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[chdb]",
"--python",
"3.12",
"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",
"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.
Optional Write Access
By default, this MCP enforces read-only queries so that accidental mutations cannot happen during exploration. To allow DDL or INSERT statements, set the CLICKHOUSE_ALLOW_WRITE_ACCESS environment variable to true. The server keeps enforcing read-only mode if the ClickHouse instance itself disallows writes.
Destructive Operation Protection
Even when write access is enabled (CLICKHOUSE_ALLOW_WRITE_ACCESS=true), destructive operations require an additional opt-in flag for safety. The check covers any DROP statement (including the ALTER TABLE ... DROP PARTITION / DROP PART / DROP COLUMN clauses), any TRUNCATE, DELETE and UPDATE (both the lightweight statements and the ALTER TABLE ... DELETE / ALTER TABLE ... UPDATE mutations), REPLACE TABLE, CREATE OR REPLACE, ALTER TABLE ... REPLACE PARTITION, ALTER TABLE ... CLEAR COLUMN / CLEAR INDEX / CLEAR PROJECTION, and DETACH ... PERMANENTLY. Keywords inside string literals, quoted identifiers, and SQL comments are ignored, so they neither trigger the check nor hide a statement from it.
This check runs in the MCP server and is a best-effort guard against accidents. It is not a security boundary. The security boundary is the ClickHouse user's grants. Read-only mode (the default) is enforced server-side via readonly=1. The destructive-operation gate is not server-enforced.
For write mode, give the MCP server a dedicated ClickHouse user with only the privileges it needs:
CREATE USER mcp_agent IDENTIFIED BY '...';
GRANT SELECT, INSERT, CREATE TABLE, ALTER ADD COLUMN ON mydb.* TO mcp_agent;Every statement outside these grants then fails server-side with ACCESS_DENIED, regardless of MCP flags. The server settings max_table_size_to_drop and max_partition_size_to_drop can also cap blast radius if pinned with settings constraints.
To enable destructive operations, set both flags:
"env": {
"CLICKHOUSE_ALLOW_WRITE_ACCESS": "true",
"CLICKHOUSE_ALLOW_DROP": "true"
}This two-tier approach makes accidental deletion difficult:
Write operations (INSERT, CREATE, ALTER ADD COLUMN) require
CLICKHOUSE_ALLOW_WRITE_ACCESS=trueDestructive operations (DROP, TRUNCATE, DELETE, UPDATE, and the rest of the list above) additionally require
CLICKHOUSE_ALLOW_DROP=true
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-clickhouseTo install chDB support as well:
python3 -m pip install 'mcp-clickhouse[chdb]'To upgrade to the latest version:
python3 -m pip install --upgrade mcp-clickhouseUpdate 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"
}
}
}
}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"
}
}
}
}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
Custom Middleware
You can add custom middleware to the MCP server without modifying the source code. FastMCP provides a middleware system that allows you to intercept and process MCP protocol messages (tool calls, resource reads, prompts, etc.).
How to Use
Create a Python module with middleware classes extending
Middlewareand asetup_middleware(mcp)function:
# my_middleware.py
import logging
from fastmcp.server.middleware import Middleware, MiddlewareContext, CallNext
logger = logging.getLogger("my-middleware")
class LoggingMiddleware(Middleware):
"""Log all tool calls."""
async def on_call_tool(self, context: MiddlewareContext, call_next: CallNext):
tool_name = context.message.name if hasattr(context.message, 'name') else 'unknown'
logger.info(f"Calling tool: {tool_name}")
result = await call_next(context)
logger.info(f"Tool {tool_name} completed")
return result
def setup_middleware(mcp):
"""Register middleware with the MCP server."""
mcp.add_middleware(LoggingMiddleware())Set the
MCP_MIDDLEWARE_MODULEenvironment variable to the module name (without.pyextension):
{
"mcpServers": {
"mcp-clickhouse": {
"command": "uv",
"args": ["run", "--with", "mcp-clickhouse", "--python", "3.12", "mcp-clickhouse"],
"env": {
"CLICKHOUSE_HOST": "<clickhouse-host>",
"CLICKHOUSE_USER": "<clickhouse-user>",
"CLICKHOUSE_PASSWORD": "<clickhouse-password>",
"MCP_MIDDLEWARE_MODULE": "my_middleware"
}
}
}
}Ensure your middleware module is in Python's import path (e.g., in the same directory where the MCP server runs, or installed as a package).
Example Middleware
An example middleware module is provided in example_middleware.py showing common patterns:
Logging all MCP requests
Logging tool calls specifically
Measuring request processing time
To use the example:
"env": {
"MCP_MIDDLEWARE_MODULE": "example_middleware"
}Middleware Capabilities
The Middleware base class provides hooks for different MCP operations:
on_message(context, call_next)- Called for all messageson_request(context, call_next)- Called for all requestson_notification(context, call_next)- Called for all notificationson_call_tool(context, call_next)- Called when a tool is executedon_read_resource(context, call_next)- Called when a resource is readon_get_prompt(context, call_next)- Called when a prompt is retrievedon_list_tools(context, call_next)- Called when listing toolson_list_resources(context, call_next)- Called when listing resourceson_list_resource_templates(context, call_next)- Called when listing resource templateson_list_prompts(context, call_next)- Called when listing prompts
Each hook receives a MiddlewareContext object containing the message and metadata, and a call_next function to continue the pipeline.
Dynamic Client Configuration via Context State
Middleware can override ClickHouse client configuration on a per-request basis using the CLIENT_CONFIG_OVERRIDES_KEY context state key. The server merges these overrides with the base configuration from environment variables.
from fastmcp.server.dependencies import get_context
from fastmcp.server.middleware import CallNext, Middleware, MiddlewareContext
from mcp_clickhouse.mcp_server import CLIENT_CONFIG_OVERRIDES_KEY
class ClientConfigMiddleware(Middleware):
async def on_call_tool(self, context: MiddlewareContext, call_next: CallNext):
ctx = get_context()
await ctx.set_state(
CLIENT_CONFIG_OVERRIDES_KEY,
{
"connect_timeout": 60,
"send_receive_timeout": 120,
},
serializable=False,
)
return await call_next(context)This enables advanced use cases like dynamic timeout adjustments, tenant-specific routing, or per-user connection settings.
The state value must be a dictionary. Nested settings and generic_args values must be
mappings and are merged with the base configuration. Invalid values fail the tool call before
a ClickHouse client is created. CLICKHOUSE_ROLE remains active unless the override explicitly
supplies settings.role. Top-level role and ch_role keys, plus the same keys under
generic_args, are rejected.
Treat these overrides as trusted middleware input. Middleware must authenticate and authorize
request-derived values before setting them. Use serializable=False so FastMCP keeps the
value in request-local state. The default serializable=True stores session state and is
rejected by the server. The server snapshots the value before dispatching blocking database
work. Do not store tenant data in session-scoped Context state. A rejected session-scoped
override remains attached to a legacy MCP session and causes later tool calls in that session
to fail until the client reconnects. A per-request ClickHouse role is connection configuration,
not a tenant authorization boundary. Enforce tenant isolation with ClickHouse users, roles,
and grants.
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
uv run fastmcp dev inspector mcp_clickhouse/mcp_server.py:mcpto start the MCP server.To test with HTTP transport and the health check endpoint:
# For development, disable authentication CLICKHOUSE_MCP_SERVER_TRANSPORT=http CLICKHOUSE_MCP_AUTH_DISABLED=true CLICKHOUSE_MCP_ALLOWED_HOSTS=127.0.0.1:8000,localhost:8000 python -m mcp_clickhouse.main # Or with authentication (generate a token first) CLICKHOUSE_MCP_SERVER_TRANSPORT=http CLICKHOUSE_MCP_AUTH_TOKEN="your-token" python -m mcp_clickhouse.main # Then in another terminal: curl http://localhost:8000/health
Environment Variables
Configuration is split into independent groups. Mixing them up is a common cause of hard-to-debug connection failures:
Group | Variables | Controls |
ClickHouse database connection |
| How this MCP server connects to your ClickHouse cluster over the HTTP interface |
MCP server / transport |
| MCP transport, authentication, and query-tool execution limits |
Middleware / chDB |
| Optional extensions |
Variables such asCLICKHOUSE_SECURE, CLICKHOUSE_VERIFY, and CLICKHOUSE_PORT apply to the ClickHouse database connection only. They do not configure TLS, ports, or auth for the MCP protocol endpoint.
Example: if the MCP server runs in Kubernetes behind an ingress that terminates TLS, that is an MCP transport concern. Keep CLICKHOUSE_SECURE aligned with how the pod reaches ClickHouse itself (HTTPS → true, plain HTTP → false). Setting CLICKHOUSE_SECURE=false because the MCP server is behind an ingress will make the server dial ClickHouse over HTTP—often against an HTTPS-only port—and produce opaque HTTP/TLS errors in the server logs.
ClickHouse database connection
These variables configure the clickhouse-connect HTTP client and the behavior of ClickHouse-backed tools such as run_query, list_databases, and list_tables.
mcp-clickhouse requires clickhouse-connect 1.0.0 or newer.
Required Variables
CLICKHOUSE_HOST: The hostname of your ClickHouse server (database endpoint, not the MCP server bind address)CLICKHOUSE_USER: The username for ClickHouse authenticationCLICKHOUSE_PASSWORD: The password for ClickHouse 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: HTTP interface port of your ClickHouse serverDefault:
8443ifCLICKHOUSE_SECURE=true,8123ifCLICKHOUSE_SECURE=falseUsually doesn't need to be set unless using a non-standard port
Must be an HTTP interface port, not the native TCP protocol port used by
clickhouse-clientCommon values:
HTTP:
8123(plain) /8443(TLS) — used by this server and ClickHouse Cloud HTTPSNative TCP (not supported here):
9000(plain) /9440(TLS) — used byclickhouse-client
If the server responds with
Port 9000 is for clickhouse-client program, you are pointed at the native protocol; switch to the HTTP port (8123/8443or your deployment's HTTP mapping)
CLICKHOUSE_ROLE: The ClickHouse role to use for authenticationDefault: None
Set this if your user requires a specific role
CLICKHOUSE_SECURE: Enable HTTPS for the ClickHouse database connection (not for MCP clients)Default:
"true"Set to
"false"only when the MCP server reaches ClickHouse over plain HTTP (typical for local Docker Compose on port8123)Leave
"true"for ClickHouse Cloud and any HTTPS database endpoint—even if the MCP server itself is exposed via HTTP, stdio, or an ingress that terminates TLS separatelyMismatching this flag with the database port (e.g.
CLICKHOUSE_SECURE=falseagainst port8443) is a frequent setup mistake and usually surfaces as confusing HTTP client errors rather than a clear "wrong scheme" message
CLICKHOUSE_VERIFY: Enable/disable SSL certificate verification for the ClickHouse HTTPS connectionDefault:
"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_SERVER_HOST_NAME: Server hostname for SNI override and certificate validation on the ClickHouse connectionDefault: None (uses the connection hostname)
This is useful when connecting through proxies or load balancers where the certificate hostname differs from the connection hostname. When set, this hostname will be used for both SNI (Server Name Indication) during the TLS handshake and for certificate hostname validation.
CLICKHOUSE_PROXY_PATH: URL path prefix for the ClickHouse HTTP endpointDefault: None
Set this when the ClickHouse HTTP interface is exposed behind a reverse proxy under a path prefix (for example,
/clickhouse)
CLICKHOUSE_CONNECT_TIMEOUT: Connection timeout in seconds for the ClickHouse clientDefault:
"30"Increase this value if you experience connection timeouts
CLICKHOUSE_SEND_RECEIVE_TIMEOUT: Send/receive timeout in seconds for the ClickHouse clientDefault: the lower of
300orCLICKHOUSE_MCP_QUERY_TIMEOUT + 5, so worker threads unblock shortly after a query timeoutIf explicitly set, the value is used as-is (e.g.
"300"for long-running queries)
CLICKHOUSE_DATABASE: Default ClickHouse database to useDefault: None (uses server default)
Set this to automatically connect to a specific database
CLICKHOUSE_ENABLED: Enable/disable ClickHouse database toolsDefault:
"true"Set to
"false"to disable ClickHouse tools when using chDB only
CLICKHOUSE_ALLOW_WRITE_ACCESS: Allow write operations (DDL and DML) against ClickHouseDefault:
"false"Set to
"true"to allow non-destructive DDL and DML (CREATE, INSERT, ALTER ADD COLUMN). Destructive statements additionally needCLICKHOUSE_ALLOW_DROP=trueWhen disabled (default), queries run with
readonly=1setting to prevent data modifications
CLICKHOUSE_ALLOW_DROP: Allow destructive operations (anyDROPorTRUNCATE,DELETEandUPDATEincluding theALTER TABLEvariants,REPLACE TABLE/REPLACE PARTITION/CREATE OR REPLACE,CLEAR COLUMN/CLEAR INDEX/CLEAR PROJECTION, andDETACH ... PERMANENTLY)Default:
"false"Only takes effect when
CLICKHOUSE_ALLOW_WRITE_ACCESS=trueis also setThis gate is a best-effort accident guard in the MCP server, not a security boundary. Restrict the ClickHouse user's grants for real enforcement (see Destructive Operation Protection)
MCP server and transport
These variables control the MCP process itself, including transport, authentication, and query-tool execution limits. They are independent of the ClickHouse database settings above. See also Authentication for HTTP/SSE Transports.
CLICKHOUSE_MCP_SERVER_TRANSPORT: Sets the transport method for the MCP serverDefault:
"stdio"Valid options:
"stdio","http","sse". This is useful for local development with tools like MCP Inspector.stdiois typical for Claude Desktop;http/sseexpose a network listener (bind host/port below)"sse"selects the deprecated standalone HTTP+SSE transport and logs a warning. Use"http"for Streamable HTTP in new deployments.
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"— not related toCLICKHOUSE_HOST
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"— not related toCLICKHOUSE_PORT
CLICKHOUSE_MCP_QUERY_TIMEOUT: Timeout in seconds for query tool callsDefault:
"30"Increase this if you see
Query timed out after ...errors for heavy queriesWhen a query times out, the server attempts to cancel it with
KILL QUERYUnless
CLICKHOUSE_SEND_RECEIVE_TIMEOUTis explicitly set, the HTTP read timeout is capped at this value plus five seconds
CLICKHOUSE_MCP_MAX_WORKERS: Maximum number of concurrent query worker threadsDefault:
"10"Increase if your workload requires many concurrent tool calls
Metadata tools use a separate pool with
min(4, CLICKHOUSE_MCP_MAX_WORKERS)threads so schema discovery cannot delay queries
CLICKHOUSE_MCP_AUTH_TOKEN: Static bearer token for HTTP/SSE transportsDefault: None
One of
CLICKHOUSE_MCP_AUTH_TOKEN,FASTMCP_SERVER_AUTH, orCLICKHOUSE_MCP_AUTH_DISABLED=trueis required for HTTP/SSE transportsGenerate using
uuidgenoropenssl rand -hex 32Clients must send this token in the
Authorization: Bearer <token>header
FASTMCP_SERVER_AUTH: Delegate authentication to a FastMCP auth providerDefault: None
Value is the full class path of an AuthProvider subclass, e.g.
fastmcp.server.auth.providers.azure.AzureProviderorfastmcp.server.auth.providers.google.GoogleProviderWhen set, mcp-clickhouse loads the provider from the existing
FASTMCP_SERVER_AUTH_*environment variables; leaveCLICKHOUSE_MCP_AUTH_TOKENunset in this modeCustom providers receive no environment-derived constructor arguments and must support no-argument construction
FastMCP 4 no longer supports Supabase HS256 verification. Supabase deployments must use RS256 or ES256.
FASTMCP_ENV_FILE: Optional file containingFASTMCP_SERVER_AUTHand provider-specific environment variablesDefault: None. When unset, the compatibility loader reads missing provider fields from
.envin the working directory. It does not readFASTMCP_SERVER_AUTHfrom that fallbackSet it in the process environment before startup. A value loaded from the default
.envcannot redirect the compatibility loaderIf process-set, this file may provide both
FASTMCP_SERVER_AUTHand provider fields and replaces the working-directory fallbackProcess environment values take precedence case-insensitively
The mcp-clickhouse compatibility loader reads this file only when building HTTP/SSE authentication and reads only
FASTMCP_SERVER_AUTHandFASTMCP_SERVER_AUTH_*entries. FastMCP 4 may read the same file for its broader settingsThe default
.envload is separate. It starts at the installedmcp_clickhousepackage directory, resolves symlinks, walks upward to the filesystem root, and loads the first.envfound or nothing. It never reads the working directory, regardless of launch method. That file may provideFASTMCP_SERVER_AUTHand provider fields along with other server settings. A source checkout normally finds the repository root.env
CLICKHOUSE_MCP_AUTH_DISABLED: Disable authentication for HTTP/SSE transportsDefault:
"false"(authentication is enabled)Set to
"true"to disable authentication for local development/testing onlyWARNING: Only use for local development. Do not disable when exposed to networks
CLICKHOUSE_MCP_ALLOWED_HOSTS: Comma separatedHostheader values the HTTP/SSE server answers forDefault for a loopback bind: bare and any-port forms of
127.0.0.1,localhost, and[::1]If set, the value must contain at least one Host entry.
A concrete non-loopback bind address defaults to that address and the configured port. A wildcard bind such as
0.0.0.0or::requires an explicit non-empty value because the public Host cannot be inferred.Host validation is a defense in depth against DNS rebinding. Origin validation below is required separately by MCP.
Entries are exact (
localhost:8000) or accept any port (localhost:*). Example:CLICKHOUSE_MCP_ALLOWED_HOSTS=127.0.0.1:8000,localhost:8000The
host:*form matches only values that carry a port. A port-less Host (a standard-port deployment where the client omits:80/:443) must be listed as a bare exact entry (example.com) as well.Requests with a non-matching or missing
Hostheader get421 Misdirected Request. GET and HEAD requests to/healthare exempt from Host and Origin validation so orchestrator probes keep working.Behind a reverse proxy, prefer preserving the original
Hostheader. You can instead list the upstreamHostvalue the proxy sends. Set an explicit list when a launcher such asfastmcp runoverrides the bind address for remote access.mcp-clickhouse forces FastMCP's separate Host and Origin guard off.
FASTMCP_HTTP_HOST_ORIGIN_PROTECTION,FASTMCP_HTTP_ALLOWED_HOSTS, andFASTMCP_HTTP_ALLOWED_ORIGINSdo not apply.CLICKHOUSE_MCP_ALLOWED_HOSTSandCLICKHOUSE_MCP_ALLOWED_ORIGINSare authoritative.
CLICKHOUSE_MCP_TRUSTED_PROXIES: Proxy IP addresses or CIDR networks whoseX-Forwarded-*headers are trustedDefault: None.
X-Forwarded-Hostis ignored. Existing Uvicorn handling ofX-Forwarded-ForandX-Forwarded-Protois unchanged.Entries must be IP addresses or CIDR networks, such as
127.0.0.1,10.20.0.0/24,2001:db8::1. CIDRs must use their network address, so10.20.0.1/24is rejected. Host names, scoped IPv6 addresses,*,0.0.0.0/0, and::/0are also rejected.Trust is based on the immediate raw socket peer. A request from any other peer, or a request without a client address, ignores
X-Forwarded-Hostand validatesHost.A trusted peer may send exactly one
X-Forwarded-Hostheader containing one non-empty value. Duplicate fields, empty values, and comma separated lists get421 Misdirected Request. If the header is absent,Hostis validated.Use the narrowest possible address or network. The MCP server must only be reachable through proxies in the configured ranges. Every trusted proxy must strip and overwrite client supplied
X-Forwarded-HostandX-Forwarded-Protovalues, and constructX-Forwarded-Forfrom the verified connection peer.The built-in server and
fastmcp rundisable Uvicorn's outer proxy-header handling, validate Host from the raw peer, then applyX-Forwarded-ForandX-Forwarded-Proto. Explicitly enablinguvicorn_config["proxy_headers"]fails startup in this mode.Direct ASGI embedding must disable proxy-header handling in the outer ASGI server and call
mcp.http_app(raw_client_address_preserved=True). Without that explicit assertion, app construction fails when trusted proxies are configured.
CLICKHOUSE_MCP_ALLOWED_ORIGINS: Comma separatedOriginheader values accepted on HTTP/SSEDefault: None, which rejects every request that carries an
OriginheaderMCP requires Origin validation for HTTP/SSE transport connections. Requests without an Origin are accepted because non-browser MCP clients normally omit it. A non-matching Origin gets
403 Forbidden. The/healthendpoint is exempt as described above.Entries are exact (
http://localhost:3000) or accept any port (http://localhost:*). As with hosts, the any-port form matches only origins that carry a port; a standard-port origin (https://app.example.com) must be listed exactly.
Reverse proxy Host handling
Preserve Host when possible. This keeps forwarded Host trust disabled:
location / {
proxy_pass http://mcp-clickhouse:8000;
proxy_set_header Host $http_host;
proxy_set_header X-Forwarded-Host "";
proxy_set_header X-Forwarded-For $remote_addr;
proxy_set_header X-Forwarded-Proto $scheme;
}Sanitize X-Forwarded-For and X-Forwarded-Proto independently of X-Forwarded-Host trust. Uvicorn may trust those headers based on the proxy peer even when CLICKHOUSE_MCP_TRUSTED_PROXIES is unset.
CLICKHOUSE_MCP_ALLOWED_HOSTS=mcp.example.comStock nginx changes Host to the upstream name for proxied requests. It does not create or overwrite X-Forwarded-Host. If preserving Host is not possible, overwrite the forwarded header at the trusted edge:
location / {
proxy_pass http://mcp-clickhouse:8000;
proxy_set_header X-Forwarded-Host $http_host;
proxy_set_header X-Forwarded-For $remote_addr;
proxy_set_header X-Forwarded-Proto $scheme;
}CLICKHOUSE_MCP_ALLOWED_HOSTS=mcp.example.com
CLICKHOUSE_MCP_TRUSTED_PROXIES=10.20.0.8The second configuration is safe only when 10.20.0.8 is the proxy's immediate source address, the server port is isolated from other clients, and nginx overwrites the incoming forwarding headers as shown. For a proxy chain, each trusted hop must discard unverified incoming values before constructing the new forwarding headers.
On an IPv6 or dual-stack bind, IPv4 proxies may appear as IPv4-mapped addresses such as ::ffff:10.20.0.8; these are matched against IPv4 entries automatically. Envoy's append_x_forwarded_host appends to an existing X-Forwarded-Host rather than overwriting it, producing a comma separated list that is rejected, so configure the trusted hop to overwrite the header instead. On Kubernetes with source NAT (for example externalTrafficPolicy: Cluster) the observed peer may be a node IP rather than the proxy pod, so trust the pod or node CIDR as appropriate; ingress-nginx overwrites both Host and X-Forwarded-Host itself.
Middleware Variables
MCP_MIDDLEWARE_MODULE: Python module name containing custom middleware to inject into the MCP serverDefault: None (no middleware loaded)
Set to the module name (without
.pyextension) of your middleware moduleThe module must provide a
setup_middleware(mcp)functionSee Custom Middleware for details and examples
chDB Variables
CHDB_ENABLED: Enable/disable chDB functionalityDefault:
"false"Set to
"true"to enable chDB toolsRequires installing the optional extra:
mcp-clickhouse[chdb]
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)
Common configuration pitfalls
CLICKHOUSE_SECUREvs MCP / ingress TLS — Turning offCLICKHOUSE_SECUREbecause the MCP server sits behind Kubernetes ingress, a reverse proxy, or is reached over plain HTTP does not disable database TLS; it only changes how this process connects to ClickHouse. Configure ingress TLS separately from the database client settings.Native protocol ports —
CLICKHOUSE_PORTmust target ClickHouse's HTTP interface (8123/8443by default). Ports9000/9440are for the native TCP protocol (clickhouse-client) and will not work with this server.Host confusion —
CLICKHOUSE_HOSTis the database hostname.CLICKHOUSE_MCP_BIND_HOSTis only the address the MCP HTTP/SSE server listens on.
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)
CLICKHOUSE_MCP_AUTH_TOKEN=your-generated-token # One auth mode required for HTTP/SSE (or FASTMCP_SERVER_AUTH, or CLICKHOUSE_MCP_AUTH_DISABLED=true)
CLICKHOUSE_MCP_ALLOWED_HOSTS=127.0.0.1:4200,localhost:4200,mcp.example.com:4200 # Include every Host value clients and proxies sendFor local development with HTTP transport (authentication disabled):
CLICKHOUSE_HOST=localhost
CLICKHOUSE_USER=default
CLICKHOUSE_PASSWORD=clickhouse
CLICKHOUSE_MCP_SERVER_TRANSPORT=http
CLICKHOUSE_MCP_AUTH_DISABLED=true # Only for local development!
CLICKHOUSE_MCP_ALLOWED_HOSTS=127.0.0.1:8000,localhost:8000When using HTTP transport, the server will run on the configured port (default 8000). For example, with the above configuration:
MCP endpoint:
http://localhost:8000/mcpHealth check:
http://localhost:8000/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",
"--python",
"3.12",
"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
CHDB_ENABLED=true uv run --extra chdb pytest -v tests/test_chdb_tool.py # chDB onlyYouTube Overview

Available Tools
1 toolrun_queryA
Execute SQL queries in ClickHouse. Queries run in read-only mode by default. Set CLICKHOUSE_ALLOW_WRITE_ACCESS=true to allow DDL and DML operations. Set CLICKHOUSE_ALLOW_DROP=true to additionally allow destructive operations (DROP, TRUNCATE).
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully bears the burden of behavioral disclosure. It correctly notes that queries are read-only by default and warns about destructive operations when enabled. This is valuable transparency, though additional details about execution limits or error handling could improve it.
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 highly concise—one sentence with bullet-like details. It front-loads the core purpose and then efficiently states behavioral notes, with no redundant 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 simple query execution tool, the description covers the key behaviors (read-only vs. write modes) and implies the output schema exists. It does not mention return value structure, but the presence of an output schema likely fills that gap.
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?
There is only one parameter ('query'), and the description does not provide any detail beyond its name and type. Since schema description coverage is 0%, the description should compensate, but it does not explain query format, constraints, or examples.
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 function: 'Execute SQL queries in ClickHouse.' The verb 'Execute' and resource 'SQL queries' are specific, distinguishing it from sibling tools that list databases or tables.
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 explains the default read-only behavior and how to enable write operations via environment variables, providing clear context for different use cases. However, it does not explicitly state when to use this tool versus sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
2 tool updates
v0.4.1- Removed
list_databases - Removed
list_tables
4 tool updates
v0.2.0- Changed
list_databases1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "description": "Generic wrapper for non-object return types.", + "properties": { + "result": { + "type": "string" + } + }, + "required": [ + "result" + ], + "type": "object", + "x-fastmcp-wrap-result": true +}
- Changed
list_tables5 fields changed- removed
Output schema / additionalPropertiesRemoved value: -true - added
Output schema / descriptionAdded value: +"Generic wrapper for non-object return types." - added
Output schema / propertiesAdded value: +{ + "result": { + "type": "string" + } +} - added
Output schema / requiredAdded value: +[ + "result" +] - added
Output schema / x-fastmcp-wrap-resultAdded value: +true
- Added
run_query - Removed
run_select_query
3 tool updates
v1.0.0- First observed
list_databases - First observed
list_tables - First observed
run_select_query
TDQS
Only one tool exists, so there is no possibility of confusion or overlap.
With a single tool, naming is trivially consistent.
A single 'run_query' tool is far too few for a ClickHouse server; users would expect multiple tools for schema management, data listing, etc.
The tool set is severely incomplete—no tools for exploring databases, tables, or performing any operation beyond raw SQL, which defeats the purpose of an MCP server.
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
Browse, query, and administer your managed WaveHouse + ClickHouse projects (schema, pipes, policy).
Query 40 databases from Claude, ChatGPT, or Cursor — on any device. Read-only, encrypted, audited.
Your Databricks Lakehouse in natural language: run SQL on your SQL warehouses, track long-running qu
Related MCP Servers
- Apache 2.0
- AlicenseNot gradedqualityDmaintenanceA Model Context Protocol server that enables Large Language Models to seamlessly interact with ClickHouse databases, supporting resource listing, schema retrieval, and query execution.2MIT
- 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
- AlicenseNot gradedqualityCmaintenanceEnables interaction with ClickHouse databases via MCP, providing tools to list databases and tables and execute safe SELECT, SHOW, and DESCRIBE queries.94MIT
Appeared in Searches
- A server for finding information about ClickHouse, the open-source column-oriented database management system
- Information about ECharts - a data visualization library
- Slack - Team Communication and Collaboration Platform
- Obtaining database schema information via an MCP server
- Methods for querying and analyzing a database
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/ClickHouse/mcp-clickhouse'
If you have feedback or need assistance with the MCP directory API, please join our Discord server