A Model Context Protocol (MCP) server that provides tools for interacting with ClickHouse® databases. This server enables AI assistants and other MCP clients to query, analyze, and interact with ClickHouse® databases through a standardized protocol.
Features
Model Context Protocol server to use ClickHouse® databases in your AI agents
Multiple Transport Options: Support for STDIO, HTTP, and Server-Sent Events (SSE) transports
Stateless MCP Protocol: The HTTP transport serves the stateless MCP protocol (spec revision 2026-07-28) — no session affinity required, safe to run behind round-robin load balancers; older clients transparently negotiate down to 2025-11-25 and earlier
OAuth 2.0 Authorization: Broker OAuth flows from MCP clients against any OIDC provider; auto-detects Bearer vs Basic auth for ClickHouse (see OAuth 2.0 Documentation)
JWE Authentication: Optional JWE-based authentication with encryption for secure database access
TLS Support: Full TLS encryption support for both ClickHouse® connections and MCP server endpoints
Comprehensive Tools: Built-in tools for listing tables, describing schemas, and executing queries
Dynamic Tools: Automatically generate MCP tools from ClickHouse® views and tables (see Tools Documentation)
Resource Templates: Dynamic resource discovery for database schemas and table information
Query Prompts: AI-assisted query building and optimization prompts
Configuration Management: Flexible configuration via files, environment variables, or CLI flags
Hot Reload: Dynamic configuration reloading without server restart
When connect_host is set, it takes precedence over HTTP_PROXY and
HTTPS_PROXY for ClickHouse HTTP connections so the configured address is
always the TCP destination. Environment proxy behavior is unchanged when
connect_host is empty.
Note: For detailed information about dynamic tools configuration, see the Tools Documentation.
Use the configuration file:
./altinity-mcp --config config.yaml
Environment Variables
Every configuration field with a flag: tag in pkg/config/config.go is settable via CLI flag or env var. The CLI flag and env-var name are listed in the field's flag: and env: tags. altinity-mcp --help prints the full surface.
Common examples:
export CLICKHOUSE_HOST=localhost
export CLICKHOUSE_PORT=8123
export CLICKHOUSE_DATABASE=analytics
export CLICKHOUSE_LIMIT=5000
export MCP_TRANSPORT=http
export MCP_PORT=8080
export MCP_METRICS_ENABLED=true
export LOG_LEVEL=debug
# OAuth — env-var injection lets operators pull secrets from a Kubernetes
# Secret via `valueFrom.secretKeyRef` instead of committing them to YAML.
export MCP_OAUTH_ENABLED=true
export MCP_OAUTH_BROKER=true
export MCP_OAUTH_ISSUER=https://accounts.example.com
export MCP_OAUTH_SIGNING_SECRET=...
./altinity-mcp
Special flags that don't follow this pattern: --config (config file path), --config-reload-time, --openapi (one flag → two struct fields). See altinity-mcp --help.
Prometheus metrics
HTTP and SSE transports (including JWE and multicluster modes) expose
/metrics when server.metrics.enabled, MCP_METRICS_ENABLED, or
--metrics-enabled is true. Metrics are disabled by default, and a disabled
server is a true no-op: no /metrics route, no request middleware, no query
instrumentation, and no collectors registered.
server.metrics.enabled is restart-only. A config reload that changes it
logs a warning and keeps the running value, because the route and middleware
are bound when the HTTP server starts.
The endpoint serves the standard Go runtime and process collectors plus:
Metric
Type
Labels
Meaning
altinity_mcp_http_requests_total
counter
route, method, status
Requests by registered route pattern, normalized method (GET, POST, ..., other) and status class (2xx, 4xx, ...)
altinity_mcp_http_request_duration_seconds
histogram
route
End-to-end handler latency
altinity_mcp_clickhouse_queries_total
counter
kind, outcome
ClickHouse queries by select/execute and ok/error
altinity_mcp_clickhouse_query_duration_seconds
histogram
kind
ClickHouse round-trip latency
altinity_mcp_clickhouse_query_rows
histogram
kind
Rows returned by successful queries
altinity_mcp_clickhouse_query_bytes
histogram
kind
Approximate bytes returned by successful queries
altinity_mcp_blocked_clause_rejections_total
counter
clause
Queries rejected by blocked_query_clauses
altinity_mcp_clickhouse_up
gauge
1/0 from the last /health readiness ping; NaN in JWE/OAuth modes where no static credentials exist
Every label is drawn from a fixed set: route labels use registered patterns
rather than raw URLs (so JWE tokens never appear), methods outside the
standard set collapse to other, and status codes collapse to their class.
The /metrics endpoint is unauthenticated. Restrict network access to it in
the same way you would for /health.
The Helm chart uses metrics.enabled for the endpoint. Set
metrics.serviceMonitor.enabled as well to create a Prometheus Operator
ServiceMonitor that scrapes the existing HTTP service port. When
config.server.tls.enabled is true the ServiceMonitor scrapes over https
automatically; supply metrics.serviceMonitor.tlsConfig if Prometheus does
not trust the server certificate.
Available Tools
execute_query
Executes SQL queries against ClickHouse® with optional result limiting.
MCP tool safety annotations:
When the server runs with --read-only, execute_query is exposed as read-only.
Otherwise execute_query is marked as potentially destructive.
Parameters:
query (required): The SQL query to execute
limit (optional): Maximum number of rows to return (default: server configured limit, max: 10,000)
Dynamic Tools
Dynamic tools generated from ClickHouse views are always exposed as read-only MCP tools with explicit safety hints.
View COMMENT supports either:
A plain string description.
A strict JSON object with top-level title, description, and annotations.
Provides complete schema information for the ClickHouse® database in JSON format.
clickhouse://table/{database}/{table}
Provides detailed information about a specific table including schema, sample data, and statistics.
Available Prompts
No prompts currently available
OpenAI GPTs Integration
The Altinity MCP Server supports seamless integration with OpenAI GPTs through its OpenAPI-compatible endpoints. These endpoints enable GPT assistants to perform ClickHouse® database operations directly.
With both: A self-contained JWE takes priority; otherwise OAuth supplies the credentials.
With both disabled: Use server-configured ClickHouse credentials.
The exact /openapi schema route also requires authentication when either mode is enabled. Dynamic HTTP/SSE tools and OpenAPI schemas use catalogs isolated by the caller's effective credential; server credentials are never a fallback under authentication. An effective configuration change resets catalog generations and requires existing SSE clients to reconnect. Unchanged reload polls preserve sessions. See dynamic discovery.
Available Actions
1. Execute Read-only SQL Query
Path: /openapi/execute_query Parameters:
jwe_token (path param): JWE authentication token
query (query param): Read-only SQL query to execute (required); writes are always rejected, even when clickhouse.read_only: false.
limit (query param): Maximum rows to return (optional, default 1000, max 10000)
Example OpenAPI Path:
GET /{jwe_token}/openapi/execute_query?query=SELECT%20*%20FROM%20table&limit=500
clickhouse.max_query_length bounds the query in bytes and dynamic-tool JSON bodies (default 10 MiB; negative disables the limit). Oversized inputs return HTTP 413 before contacting ClickHouse. OpenAPI does not expose write_query.
Note: For Altinity Cloud deployments, use the provided endpoint URL with your organization-specific token.
Authentication and Authorization
JWE takes priority when the token carries nonempty host and username claims.
A complete JWE uses its own connection fields without OAuth overrides. Partial
JWE claims fall through to OAuth and cannot alter its configured endpoint.
Invalid encrypted tokens are rejected.
OAuth 2.0 Authorization
The MCP server supports OAuth 2.0/OpenID Connect authentication, with Bearer tokens presented to ClickHouse or verified locally. This enables MCP clients to authenticate via an Identity Provider (Keycloak, Azure AD, Google, AWS Cognito) and use token-based ClickHouse authentication via token_processors.
OAuth headers, query settings, and role activation are isolated per request and cluster; forwarding a caller's bearer token does not change the configured ClickHouse headers or later requests.
When JWE authentication is enabled, the server expects tokens encrypted using AES Key Wrap (A256KW) and AES-GCM (A256GCM). These tokens contain ClickHouse® connection parameters:
JWE tokens are self-contained: host and username are required. An absent or
empty password remains empty. Server endpoint, credentials, headers, roles,
and TLS settings never fill missing claims. Only operational protocol and query
settings are inherited; an omitted port defaults to 8123 (HTTP) or 9000 (TCP).
Regenerate older tokens that relied on server connection defaults.
Nonempty token TLS file paths require server.jwe.tls_material_dir
(--jwe-tls-material-dir, MCP_JWE_TLS_MATERIAL_DIR). Paths must remain inside
that operator-controlled directory after symlink resolution. See the
JWE migration and TLS allowlist guide.
The HTTP/SSE /jwe-token-generator endpoint is disabled by default. To enable
administrative issuance, set server.jwe.token_generator.enabled: true and
inject MCP_JWE_TOKEN_GENERATOR_ADMIN_TOKEN with at least 32 bytes. Each request
requires that secret as an Authorization: Bearer token. Keep this endpoint on
a trusted administrative network and exclude it from public ingress. See the
generator setup and request limits.