What can you do with this server?

This server allows users to interact with a Timeplus cluster and Kafka streams via SQL queries and database operations. Key capabilities include: * Execute SQL Queries: Run SQL queries on the Timeplus cluster * List Databases: Retrieve all databases available on the Timeplus cluster * List Tables: Enumerate tables in a specified database * List Kafka Topics: Display topics in a connected Kafka cluster * Explore Kafka Topic: View messages from a Kafka topic * Create Kafka Stream: Set up streaming ETL in Timeplus to save Kafka messages locally * Connect to Apache Iceberg: Establish connection to Apache Iceberg database (Timeplus Enterprise only)

Which integrations are available for this server?

The MCP server is available as a package on PyPI, allowing users to install it using package managers.

How do I use mcp-timeplus?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@mcp-timeplus show me the latest 5 messages from the 'user_activity' Kafka topic" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

en es ja ko zh

mcp-timeplus

by timeplus-io

Overview Schema Related Servers Score Discussions

Python

Remote

Timeplus MCP Server

PyPI - Version

An MCP server for Timeplus.

Features

Prompts

generate_sql to give LLM more knowledge about how to query Timeplus via SQL

Tools

run_sql
- Execute SQL queries on your Timeplus cluster.
- Input: sql (string): The SQL query to execute.
- By default, all Timeplus queries are run with readonly = 1 to ensure they are safe. If you want to run DDL or DML queries, you can set the environment variable TIMEPLUS_READ_ONLY to false.
list_databases
- List all databases on your Timeplus cluster.
list_tables
- List all tables in a database.
- Input: database (string): The name of the database.
list_kafka_topics
- List all topics in a Kafka cluster
explore_kafka_topic
- Show some messages in the Kafka topic
- Input: topic (string): The name of the topic. message_count (int): The number of messages to show, default to 1.
create_kafka_stream
- Setup a streaming ETL in Timeplus to save the Kafka messages locally
- Input: topic (string): The name of the topic.
connect_to_apache_iceberg
- Connect to a database based on Apache Iceberg. Currently this is only available via Timeplus Enterprise and it's planned to make it available for Timeplus Proton soon.
- Input: iceberg_db (string): The name of the Iceberg database. aws_account_id (int): The AWS account ID (12 digits). s3_bucket (string): The S3 bucket name. aws_region (string): The AWS region, default to "us-west-2". is_s3_table_bucket (bool): Whether the S3 bucket is a S3 table bucket, default to False.

Related MCP server: Kafka MCP Server

Configuration

First, ensure you have the uv executable installed. If not, you can install it by following the instructions here.

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
Add the following:

{
  "mcpServers": {
    "mcp-timeplus": {
      "command": "uvx",
      "args": ["mcp-timeplus"],
      "env": {
        "TIMEPLUS_HOST": "<timeplus-host>",
        "TIMEPLUS_PORT": "<timeplus-port>",
        "TIMEPLUS_USER": "<timeplus-user>",
        "TIMEPLUS_PASSWORD": "<timeplus-password>",
        "TIMEPLUS_SECURE": "false",
        "TIMEPLUS_VERIFY": "true",
        "TIMEPLUS_CONNECT_TIMEOUT": "30",
        "TIMEPLUS_SEND_RECEIVE_TIMEOUT": "30",
        "TIMEPLUS_READ_ONLY": "false",
        "TIMEPLUS_KAFKA_CONFIG": "{\"bootstrap.servers\":\"a.aivencloud.com:28864\", \"sasl.mechanism\":\"SCRAM-SHA-256\",\"sasl.username\":\"avnadmin\", \"sasl.password\":\"thePassword\",\"security.protocol\":\"SASL_SSL\",\"enable.ssl.certificate.verification\":\"false\"}"
      }
    }
  }
}

Update the environment variables to point to your own Timeplus service.

Restart Claude Desktop to apply the changes.

You can also try this MCP server with other MCP clients, such as 5ire.

Development

In test-services directory run docker compose up -d to start a Timeplus Proton server. You can also download it via curl https://install.timeplus.com/oss | sh, then start with ./proton server.
Add the following variables to a .env file in the root of the repository.

TIMEPLUS_HOST=localhost
TIMEPLUS_PORT=8123
TIMEPLUS_USER=default
TIMEPLUS_PASSWORD=
TIMEPLUS_SECURE=false
TIMEPLUS_VERIFY=true
TIMEPLUS_CONNECT_TIMEOUT=30
TIMEPLUS_SEND_RECEIVE_TIMEOUT=30
TIMEPLUS_READ_ONLY=false
TIMEPLUS_KAFKA_CONFIG={"bootstrap.servers":"a.aivencloud.com:28864", "sasl.mechanism":"SCRAM-SHA-256","sasl.username":"avnadmin", "sasl.password":"thePassword","security.protocol":"SASL_SSL","enable.ssl.certificate.verification":"false"}

Run uv sync to install the dependencies. Then do source .venv/bin/activate.
For easy testing, you can run mcp dev mcp_timeplus/mcp_server.py to start the MCP server. Click the "Connect" button to connect the UI with the MCP server, then switch to the "Tools" tab to run the available tools.
To build the Docker image, run docker build -t mcp_timeplus ..

Environment Variables

The following environment variables are used to configure the Timeplus connection:

Required Variables

TIMEPLUS_HOST: The hostname of your Timeplus server
TIMEPLUS_USER: The username for authentication
TIMEPLUS_PASSWORD: The password for authentication

Optional Variables

TIMEPLUS_PORT: The port number of your Timeplus server
- Default: 8443 if HTTPS is enabled, 8123 if disabled
- Usually doesn't need to be set unless using a non-standard port
TIMEPLUS_SECURE: Enable/disable HTTPS connection
- Default: "false"
- Set to "true" for secure connections
TIMEPLUS_VERIFY: Enable/disable SSL certificate verification
- Default: "true"
- Set to "false" to disable certificate verification (not recommended for production)
TIMEPLUS_CONNECT_TIMEOUT: Connection timeout in seconds
- Default: "30"
- Increase this value if you experience connection timeouts
TIMEPLUS_SEND_RECEIVE_TIMEOUT: Send/receive timeout in seconds
- Default: "300"
- Increase this value for long-running queries
TIMEPLUS_DATABASE: Default database to use
- Default: None (uses server default)
- Set this to automatically connect to a specific database
TIMEPLUS_READ_ONLY: Enable/disable read-only mode
- Default: "true"
- Set to "false" to enable DDL/DML
TIMEPLUS_KAFKA_CONFIG: A JSON string for the Kafka configuration. Please refer to librdkafka configuration or take the above example as a reference.

Available Tools

7 tools

connect_to_apache_icebergC

Create a Timeplus database in iceberg type to connect to Iceberg

ParametersJSON Schema

Name	Required	Default
`iceberg_db`	Yes
`aws_account_id`	Yes
`s3_bucket`	Yes
`aws_region`	No	us-west-2
`is_s3_table_bucket`	No

TDQS

C2.2/5.0

Behavior1/5

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

No annotations provided, and the description does not disclose side effects, idempotency, or required permissions. Simply stating 'create' without behavioral context is insufficient.

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

Conciseness3/5

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

The description is a single sentence, making it concise, but it lacks structure or any additional useful details. It is under-specified rather than effectively concise.

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

Completeness1/5

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

With 0% schema coverage, no annotations, and no output schema, the description fails to provide enough context for correct invocation. Critical details about parameters and behavior are missing.

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

Parameters1/5

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

Schema description coverage is 0%, and the description adds no information about any of the 5 parameters. The agent must rely solely on parameter names, which are ambiguous (e.g., 'aws_account_id' may not be self-explanatory).

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

Purpose4/5

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

The description clearly states the action 'Create a Timeplus database' and the target 'to connect to Iceberg'. The verb and resource are specific, and it differentiates from sibling tools focused on Kafka or general SQL.

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 vs. alternatives, no prerequisites or conditions mentioned.

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

create_kafka_streamD

ParametersJSON Schema

Name	Required	Description	Default
`topic`	Yes

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

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

Conciseness1/5

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

Tool has no description.

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

Completeness1/5

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

Tool has no description.

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

Parameters1/5

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

Tool has no description.

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

Purpose1/5

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

Tool has no description.

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

Usage Guidelines1/5

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

Tool has no description.

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

explore_kafka_topicD

ParametersJSON Schema

Name	Required	Description	Default
`topic`	Yes
`message_count`	No

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

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

Conciseness1/5

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

Tool has no description.

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

Completeness1/5

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

Tool has no description.

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

Parameters1/5

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

Tool has no description.

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

Purpose1/5

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

Tool has no description.

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

Usage Guidelines1/5

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

Tool has no description.

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

list_databasesA

List available Timeplus databases

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A3.8/5.0

Behavior2/5

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

No annotations are provided, so the description should disclose behavioral traits. It only says 'list', implying read-only, but lacks detail on auth requirements or side effects. For a trivial tool this is marginal, but more context could be added.

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?

Single sentence with no filler. Every word earns its place. Perfectly concise.

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 simplicity (no parameters, no output schema), the description is largely complete. However, it does not specify the return format, which might be helpful.

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?

The tool has no parameters, and schema coverage is 100% (with no params). No additional parameter information is needed, so the description is adequate.

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 action (list) and resource (Timeplus databases), effectively distinguishing it from siblings like list_tables which lists tables.

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, but the simple nature of the tool implies usage for listing databases. The sibling tools cover different operations, so context is implied.

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

list_kafka_topicsD

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

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

Conciseness1/5

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

Tool has no description.

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

Completeness1/5

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

Tool has no description.

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

Parameters1/5

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

Tool has no description.

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

Purpose1/5

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

Tool has no description.

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

Usage Guidelines1/5

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

Tool has no description.

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

list_tablesC

List available tables/streams in the given database

ParametersJSON Schema

Name	Required	Description	Default
`database`	No		default
`like`	No

TDQS

C2.8/5.0

Behavior2/5

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

With no annotations, the description must disclose behavioral traits. It only states the basic action but provides no details on side effects, read-only nature, permissions needed, or performance implications.

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 a single, concise sentence that front-loads the main action. It could be slightly improved by adding parameter details without becoming verbose.

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

Completeness2/5

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

For a simple list tool, the description lacks essential context: no output schema, no explanation of the 'like' parameter, and no mention of error handling or return format. An agent may struggle to use it correctly.

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

Parameters1/5

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

Schema description coverage is 0%, and the description adds no meaning to the parameters (database, like). The 'like' parameter's purpose (filtering pattern) is not explained, leaving the agent to guess.

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', resource 'tables/streams', and scope 'in the given database', which distinguishes it from sibling tools like list_databases or list_kafka_topics.

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 alternatives, when not to use it, or any prerequisites. The description lacks context for appropriate invocation.

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

run_sqlC

Run a query in a Timeplus database

ParametersJSON Schema

Name	Required	Description	Default
`query`	Yes

TDQS

C2.3/5.0

Behavior1/5

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

With no annotations provided, the description must disclose behavioral traits. However, it only states 'Run a query' without indicating potential side effects, required permissions, query limits, or whether results are returned. This is insufficient for a tool that executes arbitrary SQL.

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

Conciseness2/5

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

The description is very short (one sentence), which might seem concise, but it is under-specified. It lacks critical information needed for proper tool usage, making it insufficient rather than appropriately concise.

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

Completeness1/5

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

Given the complexity of executing SQL queries, the absence of output schema, and no annotations, the description is woefully incomplete. It does not explain return values, error handling, or whether the query can be any valid SQL statement.

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

Parameters1/5

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

The input schema has a single required parameter 'query' with no description, and the schema description coverage is 0%. The description adds minimal meaning beyond 'run a query', failing to explain what type of SQL is supported, syntax constraints, or how to specify parameters.

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 'Run a query in a Timeplus database' clearly specifies the action (run) and the resource (query in a Timeplus database). It effectively distinguishes this tool from sibling tools like connect_to_apache_iceberg or list_tables, as it is the only one focused on executing SQL 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?

The description provides no guidance on when to use this tool versus alternatives. For example, it does not clarify whether it supports read-only queries or modifications, nor does it mention any prerequisites or restrictions.

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. Dates show when Glama detected each change.

7 tool updatesAug 18, 2025
- First observedconnect_to_apache_iceberg
- First observedcreate_kafka_stream
- First observedexplore_kafka_topic
- First observedlist_databases
- First observedlist_kafka_topics
- First observedlist_tables
- First observedrun_sql

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

C2.3/5.0

Disambiguation4/5

Most tools have distinct purposes, such as list_databases, list_tables, and run_sql, which clearly target different operations. However, create_kafka_stream and explore_kafka_topic could be slightly ambiguous if an agent needs to understand the exact boundary between creating and exploring Kafka topics, but descriptions likely clarify this.

Naming Consistency4/5

The tools follow a consistent verb_noun pattern, like list_databases and run_sql, with clear and readable names. There is a minor deviation with connect_to_apache_iceberg, which uses a longer, more specific name, but overall the naming is mostly consistent and predictable.

Tool Count5/5

With 7 tools, the count is well-scoped for a Timeplus server, covering essential operations like listing resources, creating streams, and running queries. Each tool appears to earn its place without feeling too thin or overloaded, fitting typical server purposes.

Completeness3/5

The tool set covers key operations such as listing databases/tables and running SQL, but there are notable gaps in CRUD lifecycle coverage. For example, there are no tools for updating or deleting databases, streams, or tables, which could limit agent workflows in managing Timeplus resources.

Maintenance

ActivityInactive

ResponsivenessSyncing

Resources

GitHub Repository

Need Help?

Reddit Discussion

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Databricks B
io.github.mcp-dir
Your Databricks Lakehouse in natural language: run SQL on your SQL warehouses, track long-running qu
Data Platforms Databases
171
toolsOAuth
com.streamkap
Streamkap CLI & MCP server - manage CDC pipelines, sources, destinations, and transforms
Data Platforms Databases
1
kafka-and-postgres-monitoring-stack
ai.getvda
Kafka and Postgres Monitoring Stack
1
ToolbeltOAuth
io.github.toolbeltai
A collaborative substrate over your data: vector, knowledge graph, SQL, geospatial, streaming.
Data Platforms RAG Systems Databases
21

Related MCP Servers

mcp-clickhouseofficial
Databases Developer Tools
ClickHouse
A
license
A
quality
A
maintenance
ClickHouse database integration with schema inspection and query capabilities
Updated 2 days ago (2026-09-04 18:45 UTC)
3
866
Apache 2.0
Kafka MCP Server
RAG Systems Communication App Automation
pavanjava
A
license
Not graded
quality
D
maintenance
Enables AI models to publish and consume messages from Apache Kafka topics through a standardized interface, making it easy to integrate Kafka messaging with LLM and agent applications.
Updated a year ago (2025-05-22 09:56 UTC)
17
Apache 2.0
HybridHub
Databases Cloud Storage Data Platforms
zq940222
F
license
A
quality
Not graded
maintenance
Enables unified access to both structured databases (PostgreSQL, MySQL, SQLite, etc.) and unstructured object storage (AWS S3, Alibaba OSS, Huawei OBS, etc.) through a single interface.
Updated 9 months ago (2025-12-12 03:28 UTC)
7
-
KafkaIQ
Monitoring Observability
ojhaayush03
F
license
Not graded
quality
D
maintenance
Enables AI assistants to manage and monitor Apache Kafka clusters through natural language, providing real-time operations, health monitoring, consumer lag analysis, and temporal trend detection for intelligent cluster management.
Updated 8 months ago (2025-12-29 03:27 UTC)
-

Appeared in Searches

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

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/timeplus-io/mcp-timeplus'

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

Timeplus MCP Server

Features

Prompts

Tools

Configuration

Development

Environment Variables

Required Variables

Optional Variables

Available Tools

Tool Schema Changelog

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

mcp-clickhouseofficial

Appeared in Searches

Latest Blog Posts

MCP directory API