M
MCP Directory CURATED DIRECTORY
911 MCP servers indexed
中文
← Back to directory
C

ChMonitor

Community
AI operational advisor for ClickHouse with MCP server
How to install ↓ Compare GitHub source repository ↗
Category
Database #13 of 58
Stars
★ 301 Very popular
Transport
Streamable HTTP
Runtime
Hosted (no local runtime) · Docker
Credentials
API key / credential required
License
GPL-3.0
Last commit
64FMRS · C

chmonitor is a MCP server for ClickHouse providing read-only monitoring and AI recommendations, suitable for teams integrating ClickHouse with AI tools. It supports multiple deployment methods, has active community and documentation, but note it recommends rather than auto-executes, requiring user evaluation.

Strongest · Maintenance 15/20 Weakest · Reliability 7/20

Reliability
7/20
Security and permissions
14/20
Maintenance
15/20
Documentation
14/20
Setup experience
14/20
Why each score
Reliability 7/20
The manifest and README describe a plausible streamable-http MCP endpoint at /api/mcp with client configuration examples for Claude Code, Claude Desktop, and Cursor, claiming read-only access to schema, queries, merges, replication, and cluster health. However, no source files, tests, or CI definitions for apps/mcp were supplied, so the init/tool-list handshake, whether declared tools match real behavior, and error handling cannot be verified. README and manifest are untrusted evidence; missing evidence is a deduction, and the happy path is only plausible, which is below the 10 anchor. Score 7.
Security and permissions 14/20
The design is explicitly recommend-only/read-only ('never auto-applies DDL'), the hosted remote requires a secret Authorization header (chm_ API key or Clerk OAuth), least-privilege read-only ClickHouse connection presets are documented, telemetry is opt-in and off by default, and install examples use only placeholders (chm_your_api_key, change-me) with no real tokens — no red lines triggered. Deductions: code-level enforcement (read-only session flags, query timeouts, statement filtering, rate limiting, token scoping/rotation) cannot be verified from the supplied material; 'read-only' is only a self-description, and the unauthenticated self-hosted default is a risk if publicly exposed. Score 14.
Maintenance 15/20
The project is not archived, has a clear GPL-3.0 license, the README describes a GitHub Actions release pipeline from v* tags (Docker images, Node standalone archive, Cloudflare Workers archive, checksums) and a Build-and-Test CI badge, v0.3 migration documentation shows continued evolution, and the open-issue count is low. Deductions: no security-response channel (e.g., SECURITY.md) is mentioned, no dependency-update evidence is visible, and commit cadence/issue response cannot be verified from the README/manifest; the MCP manifest version (0.2.9) lags the app's v0.3, indicating separated and lagging versioning of the MCP component. Score 15.
Documentation 14/20
Documentation is layered: README quick start, Docker/Cloudflare Workers deployment guides, MCP client setup commands and JSON examples, auth documentation (API key/OAuth), least-privilege connection presets, support matrix, pricing/editions comparison, telemetry disclosure, an upgrade guide, and a declared llms.txt plus docs/knowledge docs. Deductions: the server manifest ships no tools list or per-tool parameter/limit documentation, and the MCP-specific docs (mcp-clients.mdx, docs/knowledge/mcp-server.md) and troubleshooting content are only referenced, not supplied, so their quality cannot be checked. Score 14.
Setup experience 14/20
The setup path is short: one Docker command with CLICKHOUSE_HOST/USER/PASSWORD, or a hosted sign-up, followed by ready-made client configurations for Claude Code (one-liner), Claude Desktop, and Cursor including the Authorization header; self-hosted instances may omit the header. Platform coverage is broad (Docker, Kubernetes/Helm, Cloudflare Workers, one-click templates). Deductions: the static calibration caps setup at 15 without verifiable execution evidence (CI/tests for the server), users must substitute the manifest's hosted URL with their own deployment URL, and API-key creation steps are referenced rather than shown. Score 14.

Static review · not runListed 2026-08-07

Read the FMRS scoring method →

Fit and risk

What it can accessUses the networkConnects to a database

Best for

  • Teams needing real-time monitoring and AI-driven optimization advice for ClickHouse
  • Developers and data engineers who want to surface ClickHouse data to AI assistants
  • Users deploying on Docker, Kubernetes, or ClickHouse Cloud

Not for

  • Users who don't need ClickHouse monitoring or optimization suggestions
  • Those seeking automatic schema changes or DDL execution (chmonitor recommends only)
  • Scenarios requiring write or modification access to ClickHouse data

Required permissions

  • Read-only access to ClickHouse system.* tables (schema, queries, merges, replication, etc.)
  • Requires a ClickHouse user with read permissions on system tables (e.g., default or a dedicated read-only user)
  • For hosted instance, a valid API key is required

Risks and side effects

  • Read-only operations, but ensure API key security to prevent unauthorized access
  • AI recommendations may be inaccurate; review before applying
  • When self-hosting, protect ClickHouse credentials (CLICKHOUSE_PASSWORD)

Setup

Before you start

Runtime：Hosted (no local runtime) · Docker

CLICKHOUSE_HOST required ClickHouse endpoint (e.g. https://host:8443); required when self-hosting, not needed for the hosted endpoint.
CLICKHOUSE_USER required ClickHouse username; docs recommend a least-privilege read-only user.
CLICKHOUSE_PASSWORD requiredsecret Password for the ClickHouse user.
CHM_API_KEY_SECRET optionalsecret Optional signing secret protecting /api/v1/* routes on self-hosted instances.
CLERK_SECRET_KEY optionalsecret Clerk secret key, needed when Clerk auth is enabled.
CLOUDFLARE_API_TOKEN optionalsecret API token needed to deploy to Cloudflare Workers; for deployers only.
Other optional settings (7)
CLICKHOUSE_TZ optional Optional timezone, e.g. UTC.
CHM_AUTH_PROVIDER optional Server-side auth provider: none, clerk, or proxy; defaults to none.
VITE_AUTH_PROVIDER optional Client auth provider (build-time inlined); legacy NEXT_PUBLIC_AUTH_PROVIDER still works as fallback.
VITE_CLERK_PUBLISHABLE_KEY optional Clerk publishable key (build-time inlined), needed to enable Clerk sign-in.
CHM_CONFIG_FILE optional Optional path to a config.toml for feature toggles and access control.
CHM_FEATURE_AGENT_ACCESS optional Optional env-based access level for the AI Agent feature (e.g. authenticated).
CHM_DISABLED_FEATURES optional Optional comma-separated list of features to disable (e.g. settings,metrics).
  1. Ensure you have a ClickHouse cluster and a chm_ API key (create via dashboard 'Operate/Authentication/API Keys').
  2. Configure your MCP client (e.g., Claude Desktop, Claude Code, Cursor) with server URL https://dash.chmonitor.dev/api/mcp and header Authorization: Bearer chm_YOUR_API_KEY.
  3. Alternatively, a self-hosted instance can run without authentication, omitting the Authorization header.
claude_desktop_config.json 
{
  "mcpServers": {
    "chmonitor": {
      "url": "https://dash.chmonitor.dev/api/mcp",
      "headers": {
        "Authorization": "Bearer chm_YOUR_API_KEY"
      }
    }
  }
}

Shown for Claude Desktop. Other clients may use a different file or key (VS Code uses "servers") — the configurator below converts it.

.vscode/mcp.json
{
  "servers": {
    "chmonitor": {
      "url": "https://dash.chmonitor.dev/api/mcp",
      "headers": {
        "Authorization": "Bearer chm_YOUR_API_KEY"
      }
    }
  }
}

Goes in your project's .vscode/mcp.json (VS Code uses a "servers" key).

Terminal
claude mcp add --transport http chmonitor https://dash.chmonitor.dev/api/mcp --header 'Authorization: Bearer chm_YOUR_API_KEY'

Run it in a terminal; replace any <…> placeholders with your own values first.

Generate and validate client config

Check that it works

After adding the MCP server in your client, chmonitor's read-only ClickHouse tools should appear in the tool list; asking "What databases and tables do I have?" and getting real schema back confirms the connection.

Troubleshooting

  1. Verify API key is valid and not revoked
  2. Confirm ClickHouse instance is reachable and network firewalls are not blocking
  3. For self-hosted, check correct CLICKHOUSE_* environment variables are set
  4. Inspect MCP server logs for authentication and connection errors

Things to try

Once connected, you can ask your AI assistant things like:

  • List the ClickHouse queries currently running and their resource usage
  • Based on system.* tables, recommend skip indexes and materialized views for my tables
  • Show the replication queue status and tell me if any replica tasks are backing up
  • Explain the EXPLAIN plan of the slowest recent query

Use cases

Monitor ClickHouse cluster health, queries, merges, and replication
Get AI-powered recommendations for schema and performance optimizations (read-only, no DDL execution)
Integrate ClickHouse with AI tools like Claude or Cursor for natural language querying

Supported clients

Claude Desktop
Claude Code
Cursor

Listed from the project's documentation, not tested by this site.

Overview

chmonitor is an open-source operational advisor for ClickHouse, providing real-time monitoring and AI-driven recommendations for indexes, partitions, and materialized views. It acts as a read-only MCP server exposing schema, queries, merges, replication, and cluster health over HTTP streamable transport, self-hostable or via cloud.

Similar servers

Compare with other MCP servers

Source revision fdafcd6059af Data synced 2026-10-12 Read the FMRS scoring method