mcp-clickhouse
OfficialClickHouse MCP Server
MCP-сервер для ClickHouse.
Возможности
Инструменты ClickHouse
run_queryВыполняет SQL-запросы к вашему кластеру ClickHouse.
Входные данные:
query(string): SQL-запрос для выполнения.По умолчанию запросы выполняются в режиме только для чтения (
CLICKHOUSE_ALLOW_WRITE_ACCESS=false), но при необходимости запись можно явно включить.
list_databasesВыводит список всех баз данных в вашем кластере ClickHouse.
list_tablesВыводит список таблиц в базе данных с постраничной навигацией.
Обязательный входной параметр:
database(string).Необязательные входные параметры:
like/not_like(string): применяет фильтрыLIKEилиNOT LIKEк именам таблиц.page_token(string): токен, возвращённый предыдущим вызовом для получения следующей страницы.page_size(int, по умолчанию50): количество таблиц, возвращаемых на одной странице.include_detailed_columns(bool, по умолчаниюtrue): когда указаноfalse, исключает метаданные столбцов для более лёгких ответов, сохраняя полныйcreate_table_query.
Формат ответа:
tables: массив объектов таблиц для текущей страницы.next_page_token: передайте это значение обратно, чтобы получить следующую страницу, илиnull, если таблиц больше нет.total_tables: общее количество таблиц, соответствующих указанным фильтрам.
Инструменты chDB
run_chdb_select_queryВыполняет SQL-запросы с использованием встроенного движка ClickHouse от chDB.
Входные данные:
query(string): SQL-запрос для выполнения.Запрашивает данные напрямую из различных источников (файлов, URL, баз данных) без ETL-процессов.
Требуется дополнительный пакет
chdb:pip install 'mcp-clickhouse[chdb]'
Конечная точка проверки состояния
При использовании HTTP- или SSE-транспорта доступна конечная точка проверки состояния /health. Эта конечная точка:
Возвращает
200 OK(тело:OK), если сервер работает нормально и может подключиться к ClickHouseВозвращает
503 Service Unavailableс общим сообщением об ошибке, если сервер не может подключиться к ClickHouse
GET- и HEAD-запросы к этой конечной точке намеренно не требуют аутентификации и освобождены от проверки Host и Origin, чтобы проверки оркестратора (например, liveness/readiness в Kubernetes, балансировщики нагрузки) могли использовать назначенные во время выполнения IP-адреса подов или целевые IP-адреса без дополнительной настройки. /health зарезервирована и не может использоваться как путь MCP-транспорта. Тело ответа намеренно минимально, чтобы не раскрывать строки версий бэкенда или детали ошибок; диагностируйте сбои через журналы сервера.
Пример:
curl http://localhost:8000/health
# Response: OKRelated MCP server: ClickHouse MCP Server
Безопасность
Аутентификация для HTTP/SSE-транспортов
При использовании HTTP- или SSE-транспорта аутентификация обязательна по умолчанию. Транспорт stdio (по умолчанию) не требует аутентификации, поскольку он обменивается данными только через стандартный ввод/вывод.
Поддерживаются три режима аутентификации. Выберите один:
Режим | Когда использовать | Переменная окружения |
Статический bearer-токен | Простые развёртывания, внутренние сервисы |
|
OAuth / OIDC (через FastMCP) | Azure Entra, Google, GitHub, WorkOS и т. д. |
|
Отключена | Только локальная разработка |
|
Запуск завершается ошибкой, если ни один из этих режимов не настроен для HTTP/SSE-транспортов.
Настройка аутентификации
Сгенерируйте безопасный токен (это может быть любая случайная строка):
# Using uuidgen (macOS/Linux) uuidgen # Using openssl openssl rand -hex 32Настройте сервер с этим токеном:
export CLICKHOUSE_MCP_AUTH_TOKEN="your-generated-token"Настройте ваш MCP-клиент на включение токена в запросы:
Для Claude Desktop с HTTP/SSE-транспортом:
{ "mcpServers": { "mcp-clickhouse": { "url": "http://127.0.0.1:8000", "headers": { "Authorization": "Bearer your-generated-token" } } } }Примечание: конечная точка
/healthнамеренно не требует аутентификации (см. Конечная точка проверки состояния выше). Чтобы убедиться, что аутентификация по bearer-токену действительно отклоняет запросы без аутентификации, обратитесь к самой MCP-конечной точке, например с помощью MCP Inspector, или отправьте POST-запрос JSON-RPC на/mcpс заголовкомAuthorizationи без него и подтвердите, что вызов без аутентификации возвращает401.
OAuth / OIDC через FastMCP
Для производственных развёртываний с провайдерами удостоверений (Azure Entra, Google, GitHub, WorkOS и т. д.) делегируйте аутентификацию встроенным провайдерам аутентификации FastMCP вместо использования статического токена. Установите FASTMCP_SERVER_AUTH в полный путь класса провайдера аутентификации FastMCP, вместе с зависящими от провайдера переменными FASTMCP_SERVER_AUTH_*, и оставьте CLICKHOUSE_MCP_AUTH_TOKEN не заданной.
Пример (Azure Entra):
export FASTMCP_SERVER_AUTH=fastmcp.server.auth.providers.azure.AzureProvider
export FASTMCP_SERVER_AUTH_AZURE_TENANT_ID="<tenant-id>"
export FASTMCP_SERVER_AUTH_AZURE_CLIENT_ID="<client-id>"
export FASTMCP_SERVER_AUTH_AZURE_CLIENT_SECRET="<client-secret>"Полный список провайдеров и требуемых для них переменных окружения см. в документации FastMCP.
Режим разработки (отключение аутентификации)
Только для локальной разработки и тестирования вы можете отключить аутентификацию, установив:
export CLICKHOUSE_MCP_AUTH_DISABLED=true
export CLICKHOUSE_MCP_ALLOWED_HOSTS=127.0.0.1:8000,localhost:8000ПРЕДУПРЕЖДЕНИЕ: Используйте это только для локальной разработки. Не отключайте аутентификацию, если сервер доступен из какой-либо сети.
Конфигурация
Этот MCP-сервер поддерживает и ClickHouse, и chDB. Вы можете включить любой из них или оба в зависимости от ваших потребностей.
Откройте файл конфигурации Claude Desktop, расположенный по адресу:
На macOS:
~/Library/Application Support/Claude/claude_desktop_config.jsonНа Windows:
%APPDATA%/Claude/claude_desktop_config.json
Добавьте следующее:
{
"mcpServers": {
"mcp-clickhouse": {
"command": "uv",
"args": [
"run",
"--with",
"mcp-clickhouse",
"--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"
}
}
}
}Обновите переменные окружения, чтобы они указывали на ваш собственный сервис ClickHouse.
Или, если вы хотите попробовать его с ClickHouse SQL Playground, вы можете использовать следующую конфигурацию:
{
"mcpServers": {
"mcp-clickhouse": {
"command": "uv",
"args": [
"run",
"--with",
"mcp-clickhouse",
"--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"
}
}
}
}Для chDB (встроенный движок ClickHouse) добавьте следующую конфигурацию:
{
"mcpServers": {
"mcp-clickhouse": {
"command": "uv",
"args": [
"run",
"--with",
"mcp-clickhouse[chdb]",
"--python",
"3.10",
"mcp-clickhouse"
],
"env": {
"CHDB_ENABLED": "true",
"CLICKHOUSE_ENABLED": "false",
"CHDB_DATA_PATH": "/path/to/chdb/data"
}
}
}
}Вы также можете включить ClickHouse и chDB одновременно:
{
"mcpServers": {
"mcp-clickhouse": {
"command": "uv",
"args": [
"run",
"--with",
"mcp-clickhouse[chdb]",
"--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"
}
}
}
}Найдите запись команды для
uvи замените её абсолютным путём к исполняемому файлуuv. Это гарантирует, что при запуске сервера будет использоваться правильная версияuv. На Mac вы можете найти этот путь с помощьюwhich uv.Перезапустите Claude Desktop, чтобы изменения вступили в силу.
Необязательный доступ на запись
По умолчанию этот MCP обеспечивает выполнение запросов только для чтения, чтобы во время исследования не происходило случайных изменений. Чтобы разрешить операторы DDL или INSERT, установите переменную окружения CLICKHOUSE_ALLOW_WRITE_ACCESS в значение true. Сервер продолжит принудительно обеспечивать режим только для чтения, если сам экземпляр ClickHouse запрещает запись.
Защита от разрушительных операций
Даже когда доступ на запись включён (CLICKHOUSE_ALLOW_WRITE_ACCESS=true), разрушительные операции требуют дополнительного флага явного согласия для безопасности. Проверка охватывает любой оператор DROP (включая предложения ALTER TABLE ... DROP PARTITION / DROP PART / DROP COLUMN), любые TRUNCATE, DELETE и UPDATE (как лёгкие операторы, так и мутации ALTER TABLE ... DELETE / ALTER TABLE ... UPDATE), REPLACE TABLE, CREATE OR REPLACE, ALTER TABLE ... REPLACE PARTITION, ALTER TABLE ... CLEAR COLUMN / CLEAR INDEX / CLEAR PROJECTION, а также DETACH ... PERMANENTLY. Ключевые слова внутри строковых литералов, идентификаторов в кавычках и SQL-комментариев игнорируются, поэтому они не запускают проверку и не скрывают оператор от неё.
Эта проверка выполняется на MCP-сервере и является защитой от случайностей по принципу best-effort. Она не является границей безопасности. Границей безопасности являются привилегии пользователя ClickHouse. Режим только для чтения (по умолчанию) обеспечивается на стороне сервера через readonly=1. Ограничение разрушительных операций не обеспечивается на стороне сервера.
Для режима записи предоставьте MCP-серверу отдельного пользователя ClickHouse только с необходимыми привилегиями:
CREATE USER mcp_agent IDENTIFIED BY '...';
GRANT SELECT, INSERT, CREATE TABLE, ALTER ADD COLUMN ON mydb.* TO mcp_agent;Любой оператор за пределами этих привилегий затем завершится ошибкой на стороне сервера с ACCESS_DENIED, независимо от флагов MCP. Серверные настройки max_table_size_to_drop и max_partition_size_to_drop также могут ограничить радиус поражения, если их зафиксировать ограничениями настроек.
Чтобы включить разрушительные операции, установите оба флага:
"env": {
"CLICKHOUSE_ALLOW_WRITE_ACCESS": "true",
"CLICKHOUSE_ALLOW_DROP": "true"
}Такой двухуровневый подход затрудняет случайное удаление:
Операции записи (INSERT, CREATE, ALTER ADD COLUMN) требуют
CLICKHOUSE_ALLOW_WRITE_ACCESS=trueРазрушительные операции (DROP, TRUNCATE, DELETE, UPDATE и остальные из списка выше) дополнительно требуют
CLICKHOUSE_ALLOW_DROP=true
Запуск без uv (с использованием системного Python)
Если вы предпочитаете использовать системную установку Python вместо uv, вы можете установить пакет из PyPI и запускать его напрямую:
Установите пакет с помощью pip:
python3 -m pip install mcp-clickhouseЧтобы также установить поддержку chDB:
python3 -m pip install 'mcp-clickhouse[chdb]'Чтобы обновиться до последней версии:
python3 -m pip install --upgrade mcp-clickhouseОбновите конфигурацию Claude Desktop, чтобы использовать Python напрямую:
{
"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"
}
}
}
}Кроме того, вы можете использовать установленный скрипт напрямую:
{
"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"
}
}
}
}Примечание: обязательно используйте полный путь к исполняемому файлу Python или скрипту mcp-clickhouse, если их нет в системном PATH. Вы можете найти пути с помощью:
which python3— для исполняемого файла Pythonwhich mcp-clickhouse— для установленного скрипта
Пользовательское промежуточное ПО
Вы можете добавить пользовательское промежуточное ПО на MCP-сервер без изменения исходного кода. FastMCP предоставляет систему промежуточного ПО, которая позволяет перехватывать и обрабатывать сообщения протокола MCP (вызовы инструментов, чтение ресурсов, подсказки и т. д.).
Как использовать
Создайте Python-модуль с классами промежуточного ПО, расширяющими
Middleware, и функциейsetup_middleware(mcp):
# my_middleware.py
import logging
from fastmcp.server.middleware import Middleware, MiddlewareContext, CallNext
logger = logging.getLogger("my-middleware")
class LoggingMiddleware(Middleware):
"""Log all tool calls."""
async def on_call_tool(self, context: MiddlewareContext, call_next: CallNext):
tool_name = context.message.name if hasattr(context.message, 'name') else 'unknown'
logger.info(f"Calling tool: {tool_name}")
result = await call_next(context)
logger.info(f"Tool {tool_name} completed")
return result
def setup_middleware(mcp):
"""Register middleware with the MCP server."""
mcp.add_middleware(LoggingMiddleware())Установите переменную окружения
MCP_MIDDLEWARE_MODULEв имя модуля (без расширения.py):
{
"mcpServers": {
"mcp-clickhouse": {
"command": "uv",
"args": ["run", "--with", "mcp-clickhouse", "--python", "3.10", "mcp-clickhouse"],
"env": {
"CLICKHOUSE_HOST": "<clickhouse-host>",
"CLICKHOUSE_USER": "<clickhouse-user>",
"CLICKHOUSE_PASSWORD": "<clickhouse-password>",
"MCP_MIDDLEWARE_MODULE": "my_middleware"
}
}
}
}Убедитесь, что ваш модуль промежуточного ПО находится в пути импорта Python (например, в том же каталоге, где запускается MCP-сервер, или установлен как пакет).
Пример промежуточного ПО
Пример модуля промежуточного ПО приведён в example_middleware.py и демонстрирует распространённые шаблоны:
Журналирование всех MCP-запросов
Журналирование вызовов инструментов
Измерение времени обработки запросов
Чтобы использовать пример:
"env": {
"MCP_MIDDLEWARE_MODULE": "example_middleware"
}Возможности промежуточного ПО
Базовый класс Middleware предоставляет хуки для различных операций MCP:
on_message(context, call_next)— вызывается для всех сообщенийon_request(context, call_next)— вызывается для всех запросовon_notification(context, call_next)— вызывается для всех уведомленийon_call_tool(context, call_next)— вызывается при выполнении инструментаon_read_resource(context, call_next)— вызывается при чтении ресурсаon_get_prompt(context, call_next)— вызывается при получении подсказкиon_list_tools(context, call_next)— вызывается при выводе списка инструментовon_list_resources(context, call_next)— вызывается при выводе списка ресурсовon_list_resource_templates(context, call_next)— вызывается при выводе списка шаблонов ресурсовon_list_prompts(context, call_next)— вызывается при выводе списка подсказок
Каждый хук получает объект MiddlewareContext, содержащий сообщение и метаданные, а также функцию call_next для продолжения конвейера.
Динамическая конфигурация клиента через состояние контекста
Промежуточное ПО может переопределять конфигурацию клиента ClickHouse для каждого запроса, используя ключ состояния контекста CLIENT_CONFIG_OVERRIDES_KEY. Сервер объединяет эти переопределения с базовой конфигурацией из переменных окружения.
from fastmcp.server.dependencies import get_context
from mcp_clickhouse.mcp_server import CLIENT_CONFIG_OVERRIDES_KEY
ctx = get_context()
ctx.set_state(CLIENT_CONFIG_OVERRIDES_KEY, {
"connect_timeout": 60,
"send_receive_timeout": 120
})Это открывает возможности для продвинутых сценариев использования, таких как динамическая настройка тайм-аутов, маршрутизация для конкретных тенантов или настройки подключения для отдельных пользователей.
Значение состояния должно быть словарём. Вложенные значения settings и generic_args должны быть сопоставлениями (mappings) и объединяются с базовой конфигурацией. Недопустимые значения приводят к ошибке вызова инструмента до создания клиента ClickHouse. CLICKHOUSE_ROLE остаётся активной, если только переопределение явно не задаёт settings.role. Ключи верхнего уровня role и ch_role, а также те же ключи в generic_args, отклоняются.
Относитесь к этим переопределениям как к доверенным входным данным промежуточного слоя. Промежуточный слой должен аутентифицировать и авторизовать значения, полученные из запроса, перед их установкой. Роль ClickHouse для конкретного запроса — это конфигурация подключения, а не граница авторизации арендатора. Обеспечивайте изоляцию арендаторов с помощью пользователей, ролей и грантов ClickHouse.
Разработка
В каталоге
test-servicesвыполнитеdocker compose up -d, чтобы запустить кластер ClickHouse.Добавьте следующие переменные в файл
.envв корне репозитория.
Примечание: использование пользователя default в данном контексте предназначено исключительно для целей локальной разработки.
CLICKHOUSE_HOST=localhost
CLICKHOUSE_PORT=8123
CLICKHOUSE_USER=default
CLICKHOUSE_PASSWORD=clickhouseВыполните
uv syncдля установки зависимостей. Чтобы установитьuv, следуйте инструкциям здесь. Затем выполнитеsource .venv/bin/activate.Для удобного тестирования с помощью MCP Inspector запустите
fastmcp dev mcp_clickhouse/mcp_server.py, чтобы запустить MCP-сервер.Чтобы проверить HTTP-транспорт и эндпоинт проверки работоспособности:
# For development, disable authentication CLICKHOUSE_MCP_SERVER_TRANSPORT=http CLICKHOUSE_MCP_AUTH_DISABLED=true CLICKHOUSE_MCP_ALLOWED_HOSTS=127.0.0.1:8000,localhost:8000 python -m mcp_clickhouse.main # Or with authentication (generate a token first) CLICKHOUSE_MCP_SERVER_TRANSPORT=http CLICKHOUSE_MCP_AUTH_TOKEN="your-token" python -m mcp_clickhouse.main # Then in another terminal: curl http://localhost:8000/health
Переменные окружения
Конфигурация разделена на независимые группы. Их смешение — частая причина трудно диагностируемых ошибок подключения:
Группа | Переменные | Назначение |
Подключение к базе данных ClickHouse |
| Как этот MCP-сервер подключается к вашему кластеру ClickHouse через HTTP-интерфейс |
MCP-сервер / транспорт |
| Транспорт MCP, аутентификация и ограничения выполнения инструментов запросов |
Промежуточный слой / chDB |
| Необязательные расширения |
[!IMPORTANT] Такие переменные, как
CLICKHOUSE_SECURE,CLICKHOUSE_VERIFYиCLICKHOUSE_PORT, относятся только к подключению к базе данных ClickHouse. Они не настраивают TLS, порты или аутентификацию для конечной точки протокола MCP.Пример: если MCP-сервер работает в Kubernetes за ingress, который завершает TLS, это вопрос транспорта MCP. Держите
CLICKHOUSE_SECUREсогласованным с тем, как под достигает самого ClickHouse (HTTPS →true, обычный HTTP →false). УстановкаCLICKHOUSE_SECURE=falseтолько потому, что MCP-сервер находится за ingress, приведёт к тому, что сервер будет подключаться к ClickHouse по HTTP — часто к порту, поддерживающему только HTTPS — и вызовет непонятные ошибки HTTP/TLS в журналах сервера.
Подключение к базе данных ClickHouse
Эти переменные настраивают HTTP-клиент clickhouse-connect и поведение инструментов на базе ClickHouse, таких как run_query, list_databases и list_tables.
Обязательные переменные
CLICKHOUSE_HOST: имя хоста вашего сервера ClickHouse (конечная точка базы данных, а не адрес привязки MCP-сервера)CLICKHOUSE_USER: имя пользователя для аутентификации ClickHouseCLICKHOUSE_PASSWORD: пароль для аутентификации ClickHouse
[!CAUTION] Важно относиться к пользователю базы данных MCP так же, как к любому внешнему клиенту, подключающемуся к вашей базе данных, предоставляя только минимально необходимые привилегии для его работы. Использования пользователей по умолчанию или административных пользователей следует строго избегать в любое время.
Необязательные переменные
CLICKHOUSE_PORT: порт HTTP-интерфейса вашего сервера ClickHouseПо умолчанию:
8443, еслиCLICKHOUSE_SECURE=true,8123, еслиCLICKHOUSE_SECURE=falseОбычно не требуется устанавливать, если только не используется нестандартный порт
Должен быть портом HTTP-интерфейса, а не портом нативного протокола TCP, используемого
clickhouse-clientЧасто используемые значения:
HTTP:
8123(без TLS) /8443(TLS) — используются этим сервером и ClickHouse Cloud HTTPSНативный TCP (здесь не поддерживается):
9000(без TLS) /9440(TLS) — используетсяclickhouse-client
Если сервер отвечает
Port 9000 is for clickhouse-client program, вы указали на нативный протокол; переключитесь на HTTP-порт (8123/8443или HTTP-сопоставление вашего развёртывания)
CLICKHOUSE_ROLE: роль ClickHouse для аутентификацииПо умолчанию: None
Установите это, если вашему пользователю требуется конкретная роль
CLICKHOUSE_SECURE: включение HTTPS для подключения к базе данных ClickHouse (не для MCP-клиентов)По умолчанию:
"true"Устанавливайте
"false"только когда MCP-сервер подключается к ClickHouse по обычному HTTP (типично для локального Docker Compose на порту8123)Оставляйте
"true"для ClickHouse Cloud и любой HTTPS-конечной точки базы данных — даже если сам MCP-сервер доступен через HTTP, stdio или ingress, завершающий TLS отдельноНесоответствие этого флага порту базы данных (например,
CLICKHOUSE_SECURE=falseдля порта8443) — частая ошибка настройки, которая обычно проявляется как запутанные ошибки HTTP-клиента, а не как понятное сообщение «неверная схема»
CLICKHOUSE_VERIFY: включение/отключение проверки SSL-сертификата для HTTPS-подключения ClickHouseПо умолчанию:
"true"Установите
"false", чтобы отключить проверку сертификата (не рекомендуется для производственной среды)TLS-сертификаты: пакет использует хранилище доверия вашей операционной системы для проверки TLS-сертификатов через
truststore. Мы вызываемtruststore.inject_into_ssl()при запуске, чтобы обеспечить корректную обработку сертификатов. Поведение SSL по умолчанию в Python используется только как запасной вариант при возникновении непредвиденной ошибки.
CLICKHOUSE_SERVER_HOST_NAME: имя сервера для переопределения SNI и проверки сертификата при подключении к ClickHouseПо умолчанию: None (используется имя хоста подключения)
Это полезно при подключении через прокси или балансировщики нагрузки, когда имя хоста в сертификате отличается от имени хоста подключения. Если задано, это имя будет использоваться как для SNI (Server Name Indication) во время TLS-рукопожатия, так и для проверки имени хоста в сертификате.
CLICKHOUSE_PROXY_PATH: префикс пути URL для HTTP-эндпоинта ClickHouseПо умолчанию: None
Установите это, когда HTTP-интерфейс ClickHouse доступен за обратным прокси с префиксом пути (например,
/clickhouse)
CLICKHOUSE_CONNECT_TIMEOUT: таймаут подключения в секундах для клиента ClickHouseПо умолчанию:
"30"Увеличьте это значение, если возникают таймауты подключения
CLICKHOUSE_SEND_RECEIVE_TIMEOUT: таймаут отправки/получения в секундах для клиента ClickHouseПо умолчанию:
"300"Увеличьте это значение для длительных запросов
CLICKHOUSE_DATABASE: база данных ClickHouse по умолчаниюПо умолчанию: None (используется серверная база данных по умолчанию)
Установите это, чтобы автоматически подключаться к конкретной базе данных
CLICKHOUSE_ENABLED: включение/отключение инструментов базы данных ClickHouseПо умолчанию:
"true"Установите
"false", чтобы отключить инструменты ClickHouse при использовании только chDB
CLICKHOUSE_ALLOW_WRITE_ACCESS: разрешение операций записи (DDL и DML) в ClickHouseПо умолчанию:
"false"Установите
"true", чтобы разрешить неразрушающие DDL и DML (CREATE, INSERT, ALTER ADD COLUMN). Разрушающие операторы дополнительно требуютCLICKHOUSE_ALLOW_DROP=trueКогда отключено (по умолчанию), запросы выполняются с настройкой
readonly=1для предотвращения изменений данных
CLICKHOUSE_ALLOW_DROP: разрешение разрушающих операций (любойDROPилиTRUNCATE,DELETEиUPDATE, включая вариантыALTER TABLE,REPLACE TABLE/REPLACE PARTITION/CREATE OR REPLACE,CLEAR COLUMN/CLEAR INDEX/CLEAR PROJECTION, а такжеDETACH ... PERMANENTLY)По умолчанию:
"false"Действует только при установленном
CLICKHOUSE_ALLOW_WRITE_ACCESS=trueЭтот предохранитель — всего лишь попытка защитить от случайных действий в MCP-сервере, а не граница безопасности. Для реального обеспечения ограничьте гранты пользователя ClickHouse (см. Защита от разрушающих операций)
MCP-сервер и транспорт
Эти переменные управляют самим процессом MCP, включая транспорт, аутентификацию и ограничения выполнения инструментов запросов. Они не зависят от настроек базы данных ClickHouse, указанных выше. См. также Аутентификация для HTTP/SSE-транспортов.
CLICKHOUSE_MCP_SERVER_TRANSPORT: Устанавливает метод транспорта для MCP-сервераПо умолчанию:
"stdio"Допустимые значения:
"stdio","http","sse". Это полезно для локальной разработки с такими инструментами, как MCP Inspector.stdioтипичен для Claude Desktop;http/sseоткрывают сетевой слушатель (хост/порт привязки ниже)
CLICKHOUSE_MCP_BIND_HOST: Хост для привязки MCP-сервера при использовании HTTP или SSE транспортаПо умолчанию:
"127.0.0.1"Установите
"0.0.0.0"для привязки ко всем сетевым интерфейсам (полезно для Docker или удаленного доступа)Используется только когда транспорт —
"http"или"sse"— не связано сCLICKHOUSE_HOST
CLICKHOUSE_MCP_BIND_PORT: Порт для привязки MCP-сервера при использовании HTTP или SSE транспортаПо умолчанию:
"8000"Используется только когда транспорт —
"http"или"sse"— не связано сCLICKHOUSE_PORT
CLICKHOUSE_MCP_QUERY_TIMEOUT: Тайм-аут в секундах для инструментов запросовПо умолчанию:
"30"Увеличьте это значение, если вы видите ошибки
Query timed out after ...для тяжелых запросов
CLICKHOUSE_MCP_AUTH_TOKEN: Статический bearer-токен для HTTP/SSE транспортовПо умолчанию: None
Один из
CLICKHOUSE_MCP_AUTH_TOKEN,FASTMCP_SERVER_AUTHилиCLICKHOUSE_MCP_AUTH_DISABLED=trueобязателен для HTTP/SSE транспортовСгенерируйте с помощью
uuidgenилиopenssl rand -hex 32Клиенты должны отправлять этот токен в заголовке
Authorization: Bearer <token>
FASTMCP_SERVER_AUTH: Делегируйте аутентификацию провайдеру аутентификации FastMCPПо умолчанию: None
Значение — это полный путь к классу подкласса AuthProvider, например
fastmcp.server.auth.providers.azure.AzureProviderилиfastmcp.server.auth.providers.google.GoogleProviderЕсли задано, FastMCP автоматически загружает провайдера из собственных переменных окружения
FASTMCP_SERVER_AUTH_*; в этом режиме оставьтеCLICKHOUSE_MCP_AUTH_TOKENнезаданным
CLICKHOUSE_MCP_AUTH_DISABLED: Отключить аутентификацию для HTTP/SSE транспортовПо умолчанию:
"false"(аутентификация включена)Установите
"true", чтобы отключить аутентификацию только для локальной разработки/тестированияПРЕДУПРЕЖДЕНИЕ: Используйте только для локальной разработки. Не отключайте при наличии доступа из сетей
CLICKHOUSE_MCP_ALLOWED_HOSTS: Разделенные запятыми значения заголовкаHost, на которые отвечает HTTP/SSE серверПо умолчанию для loopback-привязки: формы без порта и с любым портом для
127.0.0.1,localhostи[::1]Если задано, значение должно содержать как минимум одну запись Host.
Конкретный не-loopback адрес привязки по умолчанию использует этот адрес и настроенный порт. Привязка с подстановочным знаком, такая как
0.0.0.0или::, требует явного непустого значения, поскольку публичный Host не может быть выведен.Проверка Host — это эшелонированная защита от DNS rebinding. Проверка Origin, описанная ниже, требуется отдельно согласно MCP.
Записи являются точными (
localhost:8000) или принимают любой порт (localhost:*). Пример:CLICKHOUSE_MCP_ALLOWED_HOSTS=127.0.0.1:8000,localhost:8000Форма
host:*соответствует только значениям, содержащим порт. Host без порта (развертывание на стандартном порту, когда клиент опускает:80/:443) также должен быть указан как точная запись без порта (example.com).Запросы с несовпадающим или отсутствующим заголовком
Hostполучают421 Misdirected Request. GET и HEAD запросы к/healthосвобождаются от проверки Host и Origin, чтобы проверки оркестратора продолжали работать.За обратным прокси укажите значение Host, которое прокси передает дальше. Задайте явный список, когда лаунчер, такой как
fastmcp run, переопределяет адрес привязки для удаленного доступа.
CLICKHOUSE_MCP_ALLOWED_ORIGINS: Разделенные запятыми значения заголовкаOrigin, принимаемые по HTTP/SSEПо умолчанию: None, что отклоняет каждый запрос, содержащий заголовок
OriginMCP требует проверку Origin для HTTP/SSE транспортных соединений. Запросы без Origin принимаются, поскольку небраузерные MCP-клиенты обычно его опускают. Несовпадающий Origin получает
403 Forbidden. Конечная точка/healthосвобождается от проверки, как описано выше.Записи являются точными (
http://localhost:3000) или принимают любой порт (http://localhost:*). Как и в случае с хостами, форма с любым портом соответствует только тем origin, которые содержат порт; origin на стандартном порту (https://app.example.com) должен быть указан точно.
Переменные промежуточного ПО
MCP_MIDDLEWARE_MODULE: Имя Python-модуля, содержащего пользовательское промежуточное ПО для внедрения в MCP-серверПо умолчанию: None (промежуточное ПО не загружается)
Установите имя модуля (без расширения
.py) вашего модуля промежуточного ПОМодуль должен предоставлять функцию
setup_middleware(mcp)См. Пользовательское промежуточное ПО для подробностей и примеров
Переменные chDB
CHDB_ENABLED: Включить/отключить функциональность chDBПо умолчанию:
"false"Установите
"true", чтобы включить инструменты chDBТребуется установка дополнительной зависимости:
mcp-clickhouse[chdb]
CHDB_DATA_PATH: Путь к каталогу данных chDBПо умолчанию:
":memory:"(база данных в памяти)Используйте
:memory:для базы данных в памятиИспользуйте путь к файлу для постоянного хранения (например,
/path/to/chdb/data)
Частые ошибки конфигурации
CLICKHOUSE_SECUREи MCP / ingress TLS — ОтключениеCLICKHOUSE_SECUREиз-за того, что MCP-сервер находится за Kubernetes ingress, обратным прокси или доступен по обычному HTTP, не отключает TLS базы данных; это лишь меняет способ подключения данного процесса к ClickHouse. Настройте ingress TLS отдельно от настроек клиента базы данных.Порты нативного протокола —
CLICKHOUSE_PORTдолжен указывать на HTTP-интерфейс ClickHouse (8123/8443по умолчанию). Порты9000/9440предназначены для нативного TCP-протокола (clickhouse-client) и не будут работать с этим сервером.Путаница с Host —
CLICKHOUSE_HOST— это имя хоста базы данных.CLICKHOUSE_MCP_BIND_HOST— это только адрес, на котором слушает MCP HTTP/SSE сервер.
Примеры конфигураций
Для локальной разработки с 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Для 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Для ClickHouse SQL Playground:
CLICKHOUSE_HOST=sql-clickhouse.clickhouse.com
CLICKHOUSE_USER=demo
CLICKHOUSE_PASSWORD=
# Uses secure defaults (HTTPS on port 8443)Только для chDB (в памяти):
# chDB configuration
CHDB_ENABLED=true
CLICKHOUSE_ENABLED=false
# CHDB_DATA_PATH defaults to :memory:Для chDB с постоянным хранением:
# chDB configuration
CHDB_ENABLED=true
CLICKHOUSE_ENABLED=false
CHDB_DATA_PATH=/path/to/chdb/dataДля MCP Inspector или удаленного доступа с HTTP-транспортом:
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)
CLICKHOUSE_MCP_AUTH_TOKEN=your-generated-token # One auth mode required for HTTP/SSE (or FASTMCP_SERVER_AUTH, or CLICKHOUSE_MCP_AUTH_DISABLED=true)
CLICKHOUSE_MCP_ALLOWED_HOSTS=127.0.0.1:4200,localhost:4200,mcp.example.com:4200 # Include every Host value clients and proxies sendДля локальной разработки с HTTP-транспортом (аутентификация отключена):
CLICKHOUSE_HOST=localhost
CLICKHOUSE_USER=default
CLICKHOUSE_PASSWORD=clickhouse
CLICKHOUSE_MCP_SERVER_TRANSPORT=http
CLICKHOUSE_MCP_AUTH_DISABLED=true # Only for local development!
CLICKHOUSE_MCP_ALLOWED_HOSTS=127.0.0.1:8000,localhost:8000При использовании HTTP-транспорта сервер будет работать на настроенном порту (по умолчанию 8000). Например, с приведенной выше конфигурацией:
Эндпоинт MCP:
http://localhost:8000/mcpПроверка работоспособности:
http://localhost:8000/health
Вы можете задать эти переменные в окружении, в файле .env или в конфигурации Claude Desktop:
{
"mcpServers": {
"mcp-clickhouse": {
"command": "uv",
"args": [
"run",
"--with",
"mcp-clickhouse",
"--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"
}
}
}
}Примечание: Настройки хоста и порта привязки используются только когда транспорт установлен в "http" или "sse".
Запуск тестов
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
CHDB_ENABLED=true uv run --extra chdb pytest -v tests/test_chdb_tool.py # chDB onlyОбзор YouTube

Available Tools
3 toolslist_databasesList DatabasesA
List available ClickHouse databases
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of disclosing behavior. It merely says 'list available ClickHouse databases' without indicating that it is a read-only operation, whether it requires specific permissions, or what the return structure looks like (though an output schema exists). The description adds no behavioral context beyond the obvious intent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that directly states the function with no filler or redundancy. It is appropriately sized for a simple tool with no parameters.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity, zero parameters, and presence of an output schema, the description is sufficient for an agent to understand its core function. The lack of explicit usage alternatives is a minor gap, but for a basic listing tool, the description covers the essentials.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema is empty, so there is nothing for the description to explain about parameters. According to the rubric, a baseline of 4 is appropriate when no parameters exist, and the description does not need to add anything.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
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 'available ClickHouse databases', making the tool's purpose unambiguous. It distinguishes itself from siblings like list_tables (tables) and run_query (queries) by explicitly targeting databases.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no explicit guidance on when to use this tool versus the sibling tools. While the purpose is self-evident, there is no mention of scenarios where listing databases is preferred or when a different tool (e.g., list_tables) would be more appropriate. This leaves the agent to infer usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_tablesList TablesA
List available ClickHouse tables in a database, including schema, comment, row count, and column count.
Integers outside [-9007199254740991, 9007199254740991] in table metadata are returned as decimal strings. Pagination tokens are single-use and retained for up to one hour.
| Name | Required | Description | Default |
|---|---|---|---|
| like | No | Optional LIKE pattern to filter table names | |
| database | Yes | The database to list tables from | |
| not_like | No | Optional NOT LIKE pattern to exclude table names | |
| page_size | No | Number of tables to return per page (default: 50, must be greater than 0) | |
| page_token | No | Single-use token from a previous call, retained for up to one hour | |
| include_detailed_columns | No | 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. |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden of behavioral disclosure. It does disclose two non-obvious behaviors: large integers become decimal strings, and pagination tokens are single-use and retained for one hour. This is meaningful transparency, though it does not address all potential behaviors such as sorting or default pagination size.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences with no filler. The first sentence states the core purpose and output, and the following two sentences provide essential behavioral quirks. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema made available and 100% parameter coverage, the description does not need to restate return structures or parameter details. It adequately covers the non-obvious behaviors around large integers and pagination tokenshare tokens, making it largely complete for an agent to invoke correctly. It falls short of 5 because it lacks any guidance on when to prefer this over list_databases or run_query.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Parameter descriptions in the schema already cover 100% of parameters, including defaults and semantics. The description adds minor context around pagination token behavior and output metadata, but does not need to compensate for schema gaps. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists ClickHouse tables in a database and includes specific metadata fields (schema, comment, row count, column count). This distinguishes it from sibling tools list_databases and run_query based on the resource being operated on and the nature of the operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for discovering table metadata, which contrasts with list_databases and run_query, but it never explicitly states when to use this tool over its siblings. There is no direct mention of alternatives or exclusion conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
run_queryRun QueryA
Execute SQL queries in ClickHouse. Queries run in read-only mode by default. Bind optional params by name with {name:Type} placeholders, such as {name:String} or {vector:Array(Float32)}. Values may be JSON scalars, nulls, or arrays. Pass exact large integers as decimal strings. JSON lists and objects cannot bind to Tuple and Map types. Python percent formatting and $name$ raw binary parameters are not supported. Parameter values stay out of the MCP server's normal SQL log lines, but may appear in errors and backend logs. Set CLICKHOUSE_ALLOW_WRITE_ACCESS=true to allow DDL and DML operations. Set CLICKHOUSE_ALLOW_DROP=true to additionally allow destructive operations (DROP, TRUNCATE, DELETE, UPDATE, REPLACE TABLE/PARTITION, CREATE OR REPLACE, CLEAR COLUMN/INDEX/PROJECTION, DETACH PERMANENTLY). That gate is a best-effort accident guard, not a security boundary. Integers outside [-9007199254740991, 9007199254740991] are returned as decimal strings. Two optional checks also run through this tool. Use DESCRIBE () when you need a query's output columns and types; it inspects the result schema and surfaces analysis errors such as an unknown column, but a query that describes cleanly can still fail at runtime. Consider EXPLAIN ESTIMATE before a SELECT that could be expensive; it returns the estimated parts, rows and marks read from MergeTree family tables, which is not run time and not result size. Neither runs the query body, though analysis can execute scalar subqueries.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | ||
| params | No |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully discloses behavioral traits: read-only by default, write/drop gated by environment variables, parameter binding constraints, integer handling as decimal strings, and the best-effort nature of the accident guard (not a security boundary). It even warns about parameter visibility in logs. This is exceptionally transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but every sentence delivers necessary behavioral or usage information. It's logically structured: main purpose, read-only default, parameter details, write-access gates, integer handling, and optional checks. While it could be trimmed slightly, the density of information justifies the length for a complex tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity and the presence of an output schema, the description covers all essential aspects: query execution, parameter binding, access control, integer representation, and optional DESCRIBE/EXPLAIN usage. It does not need to detail the return format since an output schema exists. Nothing an agent needs to correctly invoke this tool is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema only defines 'query' and 'params' with no descriptions, so the description carries the entire burden. It thoroughly explains parameter binding syntax ({name:Type}), acceptable value types (scalars, nulls, arrays), limitations (no Tuple/Map binding, no Python formatting), and how to pass large integers as decimal strings. This adds critical meaning far beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it executes SQL queries in ClickHouse with a specific verb and resource. It differentiates itself from sibling tools (list_databases, list_tables) by being the general-purpose query executor, and even mentions read-only default and optional write access, making its role unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance on when to use the tool for general queries, and details when to use DESCRIBE and EXPLAIN ESTIMATE for schema inspection and cost estimation. It does not explicitly say 'use list_databases for listing databases', but that's implied by sibling names and the description's scope. The read-only default and access flags also clarify permissible usage contexts.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
3 tool updates
v0.7.0- Added
list_databases - Added
list_tables - Changed
run_query3 fields changed- added
Input schema / additionalPropertiesAdded value: +false - added
Input schema / properties / paramsAdded value: +{ + "anyOf": [ + { + "additionalProperties": true, + "type": "object" + }, + { + "type": "null" + } + ], + "default": null +} - removed
Output schema / descriptionRemoved value: -"Generic wrapper for non-object return types."
2 tool updates
v0.4.1- Removed
list_databases - Removed
list_tables
4 tool updates
v0.2.0- Changed
list_databases1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "description": "Generic wrapper for non-object return types.", + "properties": { + "result": { + "type": "string" + } + }, + "required": [ + "result" + ], + "type": "object", + "x-fastmcp-wrap-result": true +}
- Changed
list_tables5 fields changed- removed
Output schema / additionalPropertiesRemoved value: -true - added
Output schema / descriptionAdded value: +"Generic wrapper for non-object return types." - added
Output schema / propertiesAdded value: +{ + "result": { + "type": "string" + } +} - added
Output schema / requiredAdded value: +[ + "result" +] - added
Output schema / x-fastmcp-wrap-resultAdded value: +true
- Added
run_query - Removed
run_select_query
3 tool updates
v1.0.0- First observed
list_databases - First observed
list_tables - First observed
run_select_query
TDQS
Scored across 3 tools
The three tools have clearly distinct purposes: listing databases, listing tables with metadata, and executing SQL queries. There is no realistic ambiguity about which tool an agent should choose for a given operation.
All tool names follow a consistent verb_noun snake_case pattern: list_databases, list_tables, and run_query. This makes the tool surface predictable and easy to navigate.
Three tools is a compact but well-scoped set for a database MCP server: discovery of databases, discovery of tables, and execution of SQL. Each tool earns its place and there is no redundancy.
The set covers the full workflow of exploring and querying a ClickHouse instance: list databases, inspect table schemas, then run queries. Advanced operations such as EXPLAIN and DESCRIBE are accessible through run_query, with write operations config-gated, so there are no obvious dead ends.
Maintenance
Related MCP Connectors
Governed access to production AI-agent traces in an existing ClickHouse store.
Query Postgres, MySQL, SQL Server, Oracle, BigQuery, ClickHouse and Redshift from your AI client.
Browse, query, and administer your managed WaveHouse + ClickHouse projects (schema, pipes, policy).
Query 40 databases from Claude, ChatGPT, or Cursor — on any device. Read-only, encrypted, audited.
Related MCP Servers
- Apache 2.0
- AlicenseNot gradedqualityDmaintenanceA Model Context Protocol server that enables Large Language Models to seamlessly interact with ClickHouse databases, supporting resource listing, schema retrieval, and query execution.2MIT
- AlicenseBqualityDmaintenanceAn 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.234 PyPI2MIT
- AlicenseNot gradedqualityCmaintenanceEnables interaction with ClickHouse databases via MCP, providing tools to list databases and tables and execute safe SELECT, SHOW, and DESCRIBE queries.46 npmMIT
Appeared in Searches
- A server for finding information about ClickHouse, the open-source column-oriented database management system
- Information about ECharts - a data visualization library
- Slack - Team Communication and Collaboration Platform
- Obtaining database schema information via an MCP server
- Methods for querying and analyzing a database