Skip to main content
Glama
alyiox

mcp-clickhousex

by alyiox

run_query

Read-only

Execute read-only SELECT queries on ClickHouse, returning results as CSV. Optionally use snapshot mode for large datasets.

Instructions

[ClickHouse] Execute read-only SELECT or WITH … SELECT.

One statement; DML, DDL, SET, SYSTEM, and similar are rejected. Max-rows cap; overflow sets truncated and row_limit. Same SQL validation as analyze_query.

Returns {data, row_count} where data is an RFC 4180 CSV string. Pass snapshot=true to persist the result to disk and receive a {snapshot_uri, row_count} instead; fetch the CSV via the snapshot resource URI.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
sqlYesRead-only SELECT or WITH … SELECT. One statement; use qualified db.table or database. Driver placeholder syntax for parameters.
profileNoProfile name; uses default profile when omitted. Src: profiles.
databaseNoSession default database for unqualified names. Src: databases.
snapshotNoWhen true, persist the full result as a CSV file and return a resource URI (chx://snapshots/{id}) instead of inline data. Use for queries that may exceed the interactive row limit (1 000). Snapshot limits apply (default 10 000 rows, hard ceiling 50 000). Entries expire after 7 days.
parametersNoNamed parameters for driver placeholders (e.g. %(name)s or {name:Type}).

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes
Behavior5/5

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

Annotations declare readOnlyHint=true and openWorldHint=true. Description aligns fully and adds rich behavioral details: max-rows cap, truncation with row_limit flag, CSV return format, snapshot persistence with expiration and limits. 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.

Conciseness5/5

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

Description is a single, well-structured paragraph with each sentence serving a distinct purpose: resource and verb, constraints, limits, return format, and snapshot alternative. No fluff.

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?

For a tool with 5 parameters, 100% schema coverage, and an output schema (not shown but indicated), the description covers purpose, constraints, limits, return format, and snapshot behavior comprehensively. No gaps given the context.

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?

Input schema has 100% description coverage, but description adds value by explaining the return format (CSV string and snapshot URI pattern) which is not in the input schema. Also reiterates constraints on sql parameter. Overall meaningfully supplements 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?

Description clearly states it executes read-only SELECT or WITH SELECT on ClickHouse. It specifies the resource ([ClickHouse] queries) and verb (execute read-only). Distinguishes from siblings like run_show and analyze_query by stating specific SQL types and validation.

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?

Explicitly states that only read-only queries are allowed, and DML/DDL/SET etc. are rejected. Mentions same validation as analyze_query, linking to a sibling. Clear context for when to use, but does not explicitly exclude alternatives or provide when-not-to-use guidance.

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

Install Server

Other Tools

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/alyiox/mcp-clickhousex'

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