io.github.Aguantar/clickhouse-dataops-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| CLICKHOUSE_HOST | No | ClickHouse HTTP host | localhost |
| CLICKHOUSE_PORT | No | ClickHouse HTTP port | 8123 |
| CLICKHOUSE_USER | No | ClickHouse username | default |
| CLICKHOUSE_DATABASE | No | Default database | cdc_pipeline |
| CLICKHOUSE_PASSWORD | No | ClickHouse password | |
| CLICKHOUSE_QUERY_TIMEOUT | No | Query timeout in seconds | 30 |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| ch_queryA | Execute a read-only SQL query against ClickHouse. Runs SELECT queries with automatic safety validation (DDL/DML blocked), LIMIT enforcement, and partition pruning analysis. Returns results with a warning if the query doesn't leverage partitioning efficiently. Args: sql: SELECT query to execute database: Target database (default: cdc_pipeline) max_rows: Maximum rows to return (default: 1000, max: 10000) |
| ch_explain_queryA | Analyze a query's execution plan and suggest optimizations. Runs EXPLAIN PLAN and EXPLAIN PIPELINE, then provides structured analysis:
This is the key differentiator from generic ClickHouse tools — it doesn't just execute queries, it advises on how to write better ones. Args: sql: The SELECT query to analyze database: Target database (default: cdc_pipeline) |
| ch_table_schemaA | Get comprehensive table metadata: columns, engine, keys, partitions, and sample data. Returns column types, partition/sorting/primary keys, TTL settings, row counts, disk usage, partition breakdown, and 5 sample rows. Essential for understanding table structure before writing queries. Args: table: Table name database: Database name (default: cdc_pipeline) |
| ch_pipeline_latencyA | Analyze CDC pipeline latency by segment. Measures latency at each stage of the pipeline:
Each segment reports p50, p95, p99, and max latency in milliseconds. Also includes data freshness (seconds behind real-time) and per-market breakdown. Args: market: Filter by market (e.g., "KRW-BTC"). Empty = all markets period: Time window — "10m", "1h", "6h", or "24h" (default: "1h") |
| ch_data_qualityA | Run data quality checks: nulls, duplicates, gaps, and market coverage. Checks for a specific date:
Args: table: Table to check (default: crypto_trades) database: Database name (default: cdc_pipeline) check_date: Date to check in YYYY-MM-DD format (default: today) |
| ch_slow_queriesA | Find slow queries with root cause diagnosis. Scans system.query_log for queries exceeding the duration threshold, then generates a diagnosis for each:
Args: hours: Look back period in hours (default: 24) min_duration_ms: Minimum query duration to report (default: 1000ms) limit: Maximum number of slow queries to return (default: 20) |
| ch_disk_usageA | Analyze disk usage by table and partition with recommendations. Returns:
Args: database: Database to analyze (default: cdc_pipeline) |
| ch_list_tablesA | List all tables with metadata and built-in descriptions. Returns table name, engine type, partition/sorting keys, row count, disk size, and a human-readable description of each table's purpose. Use this as the starting point to understand what data is available. Args: database: Database to list (default: cdc_pipeline) |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 8 tools
Each tool has a distinct purpose: data quality checks, disk usage, query analysis, table listing, pipeline latency, query execution, slow query diagnosis, and schema details. No two tools overlap in functionality; descriptions clearly differentiate them.
All tools share the 'ch_' prefix. Most use a verb_noun pattern (e.g., ch_list_tables, ch_explain_query), but 'ch_query' is just a noun and 'ch_slow_queries' is adjective_noun, causing minor inconsistency. Overall pattern is clear.
With 8 tools, the server covers a focused data operations scope without being overloaded. Each tool addresses a specific need, and the count feels well-scoped for managing and optimizing ClickHouse.
The tool set covers essential dataops tasks: exploring tables, checking schema, running queries, analyzing slow queries, explaining plans, monitoring pipeline latency, checking data quality, and disk usage. No obvious gaps for a read-optimized monitoring tool.