Set up ClickHouse MCP Server safely

The ClickHouse MCP Server connects an AI client to a ClickHouse database. The first setup should be a constrained test, not immediate production access. Begin with a non-production instance or restricted database view, a dedicated user, and a concrete question that only needs a few tables. The server can return schema metadata and query results to the AI client, so review that client's model, logging, and retention path before connecting.

Create a minimally privileged ClickHouse user

Do not put an administrator or default account into MCP configuration. Create a separate user or role with only SELECT on the necessary databases, tables, or preferably restrictive views. Read-only stops changes but does not stop sensitive-column disclosure. Remove unnecessary tables, columns, and rows at the database layer as well. Record who owns the access and rotate its password through your established secret process.

Configure a local stdio launch

Install uv and configure the official command uv run --with mcp-clickhouse --python 3.10 mcp-clickhouse in the MCP client. Set CLICKHOUSE_HOST, CLICKHOUSE_USER, and CLICKHOUSE_PASSWORD only as protected environment variables. For ClickHouse Cloud, documentation identifies HTTPS on port 8443 as the default; self-managed plain HTTP can require CLICKHOUSE_SECURE=false and port 8123. These values describe the database connection. They do not automatically configure TLS or authentication for a separate MCP HTTP endpoint.

Limit queries and result scope

Leave CLICKHOUSE_ALLOW_WRITE_ACCESS at its default false initially. The README then enforces read-only queries. Configure an appropriate CLICKHOUSE_MCP_QUERY_TIMEOUT and check that ClickHouse-side profiles, quotas, memory, and result limits match the workload. Ask for small, understandable queries in the client, such as a table list or aggregate metric, rather than allowing unrestricted SELECT *. A timeout and a tool dialog are not substitutes for grants or data minimisation.

Enable writing only after clear approval

If a workflow must create tables, insert data, or change structures, review the SQL, target object, and rollback plan first. According to the README, CLICKHOUSE_ALLOW_WRITE_ACCESS=true enables the non-destructive write class only in addition to matching ClickHouse grants. DROP, TRUNCATE, DELETE, UPDATE, and other protected variants also require CLICKHOUSE_ALLOW_DROP=true. These flags are not a security boundary. Grant corresponding database rights only for a limited time and purpose, and confirm every mutation in the client where it offers that option.

Review network exposure, prompt injection, and the model path

Under stdio, the process remains local. For HTTP or SSE, the server requires bearer-token or OAuth/OIDC authentication by default; do not disable it outside local tests. Restrict bind address and allowed Hosts/Origins, and terminate TLS at the appropriate infrastructure boundary. Treat table values, comments, and error messages as untrusted data: they can contain prompt injection intended to push an agent into exporting data, revealing credentials, or changing SQL. No such instruction may alter permission or approval rules. Also determine whether query results go to an external model, logs, or telemetry. The server is only suitably constrained for production after both database access and the model path are acceptable.