Skip to main content
Glama
AranNomante

ClickHouse MCP Agent

by AranNomante
OverviewSchemaRelated ServersScoreDiscussions
Python
Remote

Server Quality Checklist

67%
Profile completionA complete profile improves this server's visibility in search results.

  • Latest release: v0.12.0

  • Disambiguation5/5

    Each tool has a clear, distinct purpose: listing databases, listing tables with detailed metadata, and running arbitrary SQL queries. There is no overlap or ambiguity.

    Naming Consistency5/5

    All tools follow a consistent verb_noun pattern (list_databases, list_tables, run_query), making the naming predictable and easy to understand.

    Tool Count3/5

    With only 3 tools, the server feels minimal. While it covers basic discovery and query execution, a typical database agent would benefit from additional tools for schema management or data manipulation, even if read-only by default.

    Completeness4/5

    The tool set covers essential operations: database listing, table listing with schema, and arbitrary SQL execution (which can include DDL/DML with flags). Minor gaps exist, such as no dedicated tool for viewing query results metadata, but the overall coverage is good for a query-focused agent.

  • Average 4.1/5 across 3 of 3 tools scored.

    See the Tool Scores section below for per-tool breakdowns.

    • No community issues in the last 6 months
    • 0 commits in the last 12 weeks
    • Last stable release on
    • No critical vulnerability alerts
    • No high-severity vulnerability alerts
    • No code scanning findings
    • CI is passing

  • This repository is licensed under MIT License.

  • This repository includes a README.md file.

  • No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.

    Tip: use the "Try in Browser" feature on the server page to seed initial usage.

  • Add a glama.json file to provide metadata about your server.

  • If you are the author, simply .

    If the server belongs to an organization, first add glama.json to the root of your repository:

    {
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}

    Then . Browse examples.

  • Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

  • Behavior2/5

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

    With no annotations provided, the description should disclose behavioral traits such as whether the listing includes all databases or only those with specific permissions, but it only states the basic action. There is no mention of performance, side effects, or access requirements.

    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?

    The description is extremely concise, consisting of one short phrase with no redundant information. Every word serves a purpose.

    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?

    For a tool with no parameters and a simple action, the description provides the essential information. It does not mention the output schema, but that is covered by the output schema itself. It is sufficiently complete for a straightforward listing tool.

    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?

    There are zero parameters, so per the baseline the description is adequate. It correctly indicates no parameters are needed for this operation.

    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 uses a clear verb ('List') and specific resource ('available ClickHouse databases'), making the tool's purpose immediately understandable. It distinguishes from siblings like list_tables (which list tables) and run_query (which executes queries).

    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 is provided on when to use this tool versus its siblings or in what context. The description does not mention prerequisites, alternatives, or when-not-to-use scenarios.

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

  • Behavior4/5

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

    With no annotations provided, the description carries full burden. It discloses the critical behavioral trait that queries default to read-only and requires explicit flags for mutation or destruction. This covers the most important safety aspect, though it lacks details on timeouts, error handling, or response format.

    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?

    The description consists of three concise sentences, front-loading the primary purpose in the first sentence. Every sentence adds necessary information (purpose, default mode, flags for extended use) without redundancy or wordiness.

    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?

    Given the tool's complexity (single parameter, output schema exists), the description addresses key behavioral controls (read-only default, write/drop flags). It does not cover potential risks or limits, but the presence of an output schema reduces the need to document return values. Overall, it is sufficiently complete for typical usage.

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

    Parameters2/5

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

    Schema coverage is 0% for the single 'query' parameter, so the description must compensate. It only says 'SQL queries' which is minimal and does not add constraints like syntax, length limits, or examples. The parameter name is self-explanatory, but the description adds little extra value beyond the schema definition.

    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 'Execute SQL queries in ClickHouse,' specifying both the action (execute) and the resource (ClickHouse SQL queries). It distinguishes from sibling tools (list_databases, list_tables) which are listing-oriented, making the tool's unique purpose evident.

    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 provides explicit guidance on when to use write and destructive operations via environment variables (CLICKHOUSE_ALLOW_WRITE_ACCESS and CLICKHOUSE_ALLOW_DROP), setting this apart from the default read-only mode. Although it does not explicitly contrast with siblings, the context is clear for typical query execution.

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

  • Behavior5/5

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

    With no annotations, the description fully discloses behavior: returns tables with metadata, supports pagination, filtering via LIKE/NOT LIKE, and an include_detailed_columns parameter that reduces payload. No contradictions.

    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 Args and Returns sections, and every sentence adds value. It is somewhat lengthy but justified by the number of parameters and details.

    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 params, pagination, optional detailed columns) and the presence of an output schema, the description covers all aspects including return values. It is comprehensive.

    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?

    All six parameters are explained in detail in the Args section, including defaults and the effect of include_detailed_columns. The input schema has 0% description coverage, so the description compensates fully.

    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 'List available ClickHouse tables in a database, including schema, comment, row count, and column count.' It distinguishes itself from siblings list_databases and run_query by specifying tables and their metadata.

    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 provides clear context on what the tool does, but lacks explicit guidance on when to use it vs. the sibling tools (list_databases, run_query). No exclusions or alternative recommendations are mentioned.

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

GitHub Badge

Glama performs regular codebase and documentation scans to:

  • Confirm that the MCP server is working as expected.
  • Confirm that there are no obvious security issues.
  • Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

clickhousemcp MCP server

Copy to your README.md:

Score Badge

clickhousemcp MCP server

Copy to your README.md:

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/AranNomante/clickhousemcp'

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