Skip to main content
Glama
stiproot

mcp-clickhouse

by stiproot

ClickHouse MCP Server (Enhanced)

PyPI - Version

An MCP server for ClickHouse with enhanced filtering capabilities for database and table discovery.

Note: This is a fork of ClickHouse/mcp-clickhouse with added filtering support for list_databases and list_tables tools. Both functions now support single or multiple LIKE/NOT LIKE patterns for flexible database and table discovery.

What's New in This Fork

  • Multiple Pattern Support: Filter databases and tables using multiple LIKE patterns with OR logic

  • Advanced Exclusions: Exclude using multiple NOT LIKE patterns with AND logic

  • Backward Compatible: Single string patterns still work exactly as before

  • Pagination Aware: Multiple patterns work seamlessly with table pagination

Related MCP server: clickhouse-mcp-server

Features

ClickHouse Tools

  • run_select_query

    • Execute SQL queries on your ClickHouse cluster.

    • Input: sql (string): The SQL query to execute.

    • All ClickHouse queries are run with readonly = 1 to ensure they are safe.

  • list_databases

    • List databases on your ClickHouse cluster.

    • Optional inputs:

      • like (string or list of strings): Apply LIKE filter(s) to database names. Multiple patterns are combined with OR logic.

      • not_like (string or list of strings): Apply NOT LIKE filter(s) to exclude database names. Multiple patterns are combined with AND logic.

    • Examples:

      • like="prod_%" - Single pattern

      • like=["prod_%", "staging_%"] - Multiple patterns (matches either)

      • not_like=["test_%", "temp_%"] - Exclude multiple patterns (excludes both)

  • list_tables

    • List tables in a database with pagination.

    • Required input: database (string).

    • Optional inputs:

      • like (string or list of strings): Apply LIKE filter(s) to table names. Multiple patterns are combined with OR logic.

      • not_like (string or list of strings): Apply NOT LIKE filter(s) to exclude table names. Multiple patterns are combined with AND logic.

      • page_token (string): Token returned by a previous call for fetching the next page.

      • page_size (int, default 50): Number of tables returned per page.

      • include_detailed_columns (bool, default true): When false, omits column metadata for lighter responses while keeping the full create_table_query.

    • Examples:

      • like="user_%" - Single pattern

      • like=["user_%", "order_%"] - Multiple patterns (matches either)

      • not_like=["temp_%", "backup_%"] - Exclude multiple patterns (excludes both)

    • Response shape:

      • tables: Array of table objects for the current page.

      • next_page_token: Pass this value back to fetch the next page, or null when there are no more tables.

      • total_tables: Total count of tables that match the supplied filters.

chDB Tools

  • run_chdb_select_query

    • Execute SQL queries using chDB's embedded ClickHouse engine.

    • Input: sql (string): The SQL query to execute.

    • Query data directly from various sources (files, URLs, databases) without ETL processes.

Enhanced Filtering Capabilities

This fork adds powerful filtering capabilities to both list_databases and list_tables tools, allowing you to efficiently discover and filter databases and tables using SQL LIKE patterns.

Key Features

  1. Single Pattern Filtering

    • Filter with a single LIKE pattern: like="prod_%" matches all databases/tables starting with "prod_"

    • Exclude with a single NOT LIKE pattern: not_like="test_%" excludes all starting with "test_"

  2. Multiple Pattern Filtering

    • OR logic for like: like=["user_%", "order_%"] matches tables starting with "user_" OR "order_"

    • AND logic for not_like: not_like=["temp_%", "backup_%"] excludes tables starting with "temp_" AND tables starting with "backup_"

  3. Combined Filtering

    • Mix both: like=["prod_%", "staging_%"], not_like=["_backup"] includes prod/staging but excludes any ending with "_backup"

Use Cases

Scenario 1: Multi-environment Database Discovery

# Find all production and staging databases
list_databases(like=["prod_%", "staging_%"])

Scenario 2: Clean Table Listing

# List all user and order tables, but exclude temporary and backup tables
list_tables(
    database="mydb",
    like=["user_%", "order_%"],
    not_like=["temp_%", "backup_%"]
)

Scenario 3: Development Environment Cleanup

# Find all test/temp/dev databases for cleanup
list_databases(like=["test_%", "temp_%", "dev_%"])

Health Check Endpoint

When running with HTTP or SSE transport, a health check endpoint is available at /health. This endpoint:

  • Returns 200 OK with the ClickHouse version if the server is healthy and can connect to ClickHouse

  • Returns 503 Service Unavailable if the server cannot connect to ClickHouse

Example:

curl http://localhost:8000/health
# Response: OK - Connected to ClickHouse 24.3.1

Configuration

This MCP server supports both ClickHouse and chDB. You can enable either or both depending on your needs.

  1. Open the Claude Desktop configuration file located at:

    • On macOS: ~/Library/Application Support/Claude/claude_desktop_config.json

    • On Windows: %APPDATA%/Claude/claude_desktop_config.json

  2. Add the following:

{
  "mcpServers": {
    "mcp-clickhouse": {
      "command": "uv",
      "args": [
        "run",
        "--with",
        "mcp-clickhouse-like",
        "--python",
        "3.10",
        "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",
        "CLICKHOUSE_SEND_RECEIVE_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-like",
        "--python",
        "3.10",
        "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",
        "CLICKHOUSE_SEND_RECEIVE_TIMEOUT": "30"
      }
    }
  }
}

For chDB (embedded ClickHouse engine), add the following configuration:

{
  "mcpServers": {
    "mcp-clickhouse": {
      "command": "uv",
      "args": [
        "run",
        "--with",
        "mcp-clickhouse-like",
        "--python",
        "3.10",
        "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-like",
        "--python",
        "3.10",
        "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",
        "CLICKHOUSE_SEND_RECEIVE_TIMEOUT": "30",
        "CHDB_ENABLED": "true",
        "CHDB_DATA_PATH": "/path/to/chdb/data"
      }
    }
  }
}
  1. Locate the command entry for uv and replace it with the absolute path to the uv executable. This ensures that the correct version of uv is used when starting the server. On a mac, you can find this path using which uv.

  2. Restart Claude Desktop to apply the changes.

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:

  1. Install the package using pip:

    python3 -m pip install mcp-clickhouse-like

    To upgrade to the latest version:

    python3 -m pip install --upgrade mcp-clickhouse-like

    Optional chDB Support: If you want to use chDB features (embedded ClickHouse engine), install with the chdb extra:

    python3 -m pip install mcp-clickhouse-like[chdb]

    Note: chDB is not available on Windows. If you're on Windows, use the standard ClickHouse tools instead.

  2. Update 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",
        "CLICKHOUSE_SEND_RECEIVE_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",
        "CLICKHOUSE_SEND_RECEIVE_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 python3 for the Python executable

  • which mcp-clickhouse for the installed script

Development

  1. In test-services directory run docker compose up -d to start the ClickHouse cluster.

  2. Add the following variables to a .env file 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=clickhouse
  1. Run uv sync to install the dependencies. To install uv follow the instructions here. Then do source .venv/bin/activate.

  2. For easy testing with the MCP Inspector, run fastmcp dev mcp_clickhouse/mcp_server.py to start the MCP server.

  3. To test with HTTP transport and the health check endpoint:

    # Using default port 8000
    CLICKHOUSE_MCP_SERVER_TRANSPORT=http python -m mcp_clickhouse.main
    
    # Or with a custom port
    CLICKHOUSE_MCP_SERVER_TRANSPORT=http CLICKHOUSE_MCP_BIND_PORT=4200 python -m mcp_clickhouse.main
    
    # Then in another terminal:
    curl http://localhost:8000/health  # or http://localhost:4200/health for custom port

Environment Variables

The following environment variables are used to configure the ClickHouse and chDB connections:

ClickHouse Variables

Required Variables
  • CLICKHOUSE_HOST: The hostname of your ClickHouse server

  • CLICKHOUSE_USER: The username for authentication

  • CLICKHOUSE_PASSWORD: The password for authentication

CAUTION

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: The port number of your ClickHouse server

    • Default: 8443 if HTTPS is enabled, 8123 if disabled

    • Usually doesn't need to be set unless using a non-standard port

  • CLICKHOUSE_ROLE: The role to use for authentication

    • Default: None

    • Set this if your user requires a specific role

  • CLICKHOUSE_SECURE: Enable/disable HTTPS connection

    • Default: "true"

    • Set to "false" for non-secure connections

  • CLICKHOUSE_VERIFY: Enable/disable SSL certificate verification

    • Default: "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 call truststore.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_CONNECT_TIMEOUT: Connection timeout in seconds

    • Default: "30"

    • Increase this value if you experience connection timeouts

  • CLICKHOUSE_SEND_RECEIVE_TIMEOUT: Send/receive timeout in seconds

    • Default: "300"

    • Increase this value for long-running queries

  • CLICKHOUSE_DATABASE: Default database to use

    • Default: None (uses server default)

    • Set this to automatically connect to a specific database

  • CLICKHOUSE_MCP_SERVER_TRANSPORT: Sets the transport method for the MCP server.

    • Default: "stdio"

    • Valid options: "stdio", "http", "sse". This is useful for local development with tools like MCP Inspector.

  • CLICKHOUSE_MCP_BIND_HOST: Host to bind the MCP server to when using HTTP or SSE transport

    • Default: "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"

  • CLICKHOUSE_MCP_BIND_PORT: Port to bind the MCP server to when using HTTP or SSE transport

    • Default: "8000"

    • Only used when transport is "http" or "sse"

  • CLICKHOUSE_MCP_QUERY_TIMEOUT: Timeout in seconds for SELECT tools

    • Default: "30"

    • Increase this if you see Query timed out after ... errors for heavy queries

  • CLICKHOUSE_ENABLED: Enable/disable ClickHouse functionality

    • Default: "true"

    • Set to "false" to disable ClickHouse tools when using chDB only

chDB Variables

  • CHDB_ENABLED: Enable/disable chDB functionality

    • Default: "false"

    • Set to "true" to enable chDB tools

  • CHDB_DATA_PATH: The path to the chDB data directory

    • Default: ":memory:" (in-memory database)

    • Use :memory: for in-memory database

    • Use a file path for persistent storage (e.g., /path/to/chdb/data)

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=false

For 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_database

For 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/data

For 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)

When using HTTP transport, the server will run on the configured port (default 8000). For example, with the above configuration:

  • MCP endpoint: http://localhost:4200/mcp

  • Health check: http://localhost:4200/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-like",
        "--python",
        "3.10",
        "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
uv run pytest -v tests/test_chdb_tool.py # chDB only

Comparison with Upstream

This fork maintains full compatibility with the upstream project while adding enhanced filtering capabilities:

Feature

Upstream

This Fork

Single LIKE pattern

Single NOT LIKE pattern

Multiple LIKE patterns

✅ (OR logic)

Multiple NOT LIKE patterns

✅ (AND logic)

Pagination support

✅ (with patterns)

Backward compatible

-

Implementation Details

  • Type Safety: Uses Union[str, List[str]] for pattern parameters

  • SQL Generation: Patterns are properly escaped using format_query_value() to prevent SQL injection

  • Pagination: Multiple patterns are stored in the pagination cache and validated across pages

  • Performance: Generates optimized SQL with parenthesized conditions for efficient query execution

YouTube Overview (Upstream Project)

YouTube

Available Tools

3 tools
list_databasesA

List available ClickHouse databases

Args: like: Optional LIKE pattern(s) to filter database names. Can be a single string or list of strings. Multiple patterns are combined with OR logic. not_like: Optional NOT LIKE pattern(s) to exclude database names. Can be a single string or list of strings. Multiple patterns are combined with OR logic.

Returns: JSON array of database names

ParametersJSON Schema
NameRequiredDescriptionDefault
likeNo
not_likeNo

TDQS

A4/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Describes parameters and return format but does not mention read-only nature or default behavior (all databases if no filters). Annotations absent, so burden is on description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Concise docstring format with Args and Returns sections; no unnecessary words, well-organized.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Covers all parameters and return type; for a simple list tool with no output schema, it is sufficiently complete, though could mention default filtering behavior.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Adds meaning beyond schema by explaining LIKE pattern logic, OR combination, and that patterns can be strings or lists; schema coverage is 0%, so description compensates well.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool lists available ClickHouse databases, distinguishing it from siblings like list_tables and run_select_query.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No explicit guidance on when to use versus alternatives, though the purpose is distinct enough; lacks when-not-to-use or prerequisites.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

list_tablesA

List available ClickHouse tables in a database, including schema, comment, row count, and column count.

Args: database: The database to list tables from like: Optional LIKE pattern(s) to filter table names. Can be a single string or list of strings. Multiple patterns are combined with OR logic. not_like: Optional NOT LIKE pattern(s) to exclude table names. Can be a single string or list of strings. Multiple patterns are combined with OR logic. page_token: Token for pagination, obtained from a previous call page_size: Number of tables to return per page (default: 50) include_detailed_columns: Whether to include detailed column metadata (default: True). When False, the columns array will be empty but create_table_query still contains all column information. This reduces payload size for large schemas.

Returns: A dictionary containing: - tables: List of table information (as dictionaries) - next_page_token: Token for the next page, or None if no more pages - total_tables: Total number of tables matching the filters

ParametersJSON Schema
NameRequiredDescriptionDefault
databaseYes
likeNo
not_likeNo
page_tokenNo
page_sizeNo
include_detailed_columnsNo

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

A4.7/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description fully discloses behavior: pagination, LIKE/not_like filtering, and the effect of 'include_detailed_columns' on payload. It also explains the output structure, making the tool's behavior transparent.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured with clear sections for Args and Returns. It is somewhat long but each sentence adds value. It could be slightly more concise, but the structure aids readability.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the complexity (6 parameters, no annotations, output schema exists), the description covers all necessary aspects: parameter explanations, return format, pagination, and filtering. It enables correct usage without needing additional context.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema has 0% description coverage, but the description provides detailed explanations for all parameters, including their types, defaults, and behavior (e.g., multiple patterns with OR logic for like/not_like). This adds significant meaning beyond the bare schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'list' and the resource 'ClickHouse tables', and includes context like schema, comment, row count, and column count. It distinguishes from siblings 'list_databases' and 'run_select_query' which serve different purposes.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implicitly suggests using this tool for listing tables with filtering and pagination. It does not explicitly state when not to use or mention alternatives, but the sibling tool names and context make the usage clear.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

run_select_queryB

Run a SELECT query in a ClickHouse database

ParametersJSON Schema
NameRequiredDescriptionDefault
queryYes

TDQS

B3.2/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided. Description does not disclose read-only nature, potential performance impact, or required permissions. Only states the action.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Single sentence is concise and front-loaded with action. However, extremely brief for a tool that executes arbitrary SQL; could include a brief note on safety.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Simple tool, but missing details like result structure, error handling, and query restrictions. Adequate for minimal understanding but not robust.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Parameter 'query' has no schema description. Description clarifies it is a SELECT query string, but does not specify format, length limits, or syntax expectations.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Description explicitly states the action (run) and resource (SELECT query in ClickHouse database), distinguishing from sibling tools that list metadata.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool versus alternatives like list_tables. Does not exclude non-SELECT queries or advise on appropriate contexts.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

TDQS

A3.7/5.0
Disambiguation5/5

Each tool targets a distinct action: listing databases, listing tables, and running SELECT queries. No overlap in functionality.

Naming Consistency5/5

All tools follow a consistent verb_noun pattern: list_databases, list_tables, run_select_query. No mixing of conventions.

Tool Count3/5

With only 3 tools, the set is minimal for a database server but not excessively small; it covers basic browsing and querying.

Completeness2/5

The server lacks critical operations like creating or dropping databases/tables, inserting data, or describing schemas, leaving significant gaps for typical database interactions.

Maintenance

ActivityInactive
ResponsivenessNo issues

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

Related MCP Servers

  • A
    license
    B
    quality
    F
    maintenance
    An 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.
    2
    2
    MIT
  • F
    license
    Not graded
    quality
    D
    maintenance
    A multi-database MCP server supporting PostgreSQL, ClickHouse, and MySQL that enables database exploration and SQL execution through MCP stdio or HTTP API.

Latest Blog Posts

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/stiproot/mcp-clickhouse'

If you have feedback or need assistance with the MCP directory API, please join our Discord server