Skip to main content
Glama
enesjakozh
timeplus-io

mcp-timeplus

by timeplus-io
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

Timeplus MCP 服务器

PyPI - 版本

Timeplus 的 MCP 服务器。

特征

提示

  • generate_sql为 LLM 提供更多关于如何通过 SQL 查询 Timeplus 的知识

工具

  • run_sql

    • 在您的 Timeplus 集群上执行 SQL 查询。

    • 输入： sql （字符串）：要执行的 SQL 查询。

    • 默认情况下，所有 Timeplus 查询都以readonly = 1运行，以确保其安全。如果要运行 DDL 或 DML 查询，可以将环境变量TIMEPLUS_READ_ONLY设置为false 。

  • list_databases

    • 列出 Timeplus 集群上的所有数据库。

  • list_tables

    • 列出数据库中的所有表。

    • 输入： database （字符串）：数据库的名称。

  • list_kafka_topics

    • 列出 Kafka 集群中的所有主题

  • explore_kafka_topic

    • 显示 Kafka 主题中的一些消息

    • 输入： topic （字符串）：主题的名称。message_count（int）：要显示的message_count数，默认为 1。

  • create_kafka_stream

    • 在 Timeplus 中设置流式 ETL 以在本地保存 Kafka 消息

    • 输入： topic （字符串）：主题的名称。

  • connect_to_apache_iceberg

    • 连接到基于 Apache Iceberg 的数据库。目前此功能仅支持 Timeplus Enterprise，计划很快支持 Timeplus Proton。

    • 输入： iceberg_db （字符串）：Iceberg 数据库的名称aws_account_id （整数）：AWS 账户 ID（12 位数字） s3_bucket （字符串）：S3 存储桶名称。aws_region（ aws_region ）：AWS 区域，默认为“us-west-2”。is_s3_table_bucket（布尔值）：S3 is_s3_table_bucket桶是否为 S3 表存储桶，默认为 False。

Related MCP server: Kafka MCP Server

配置

首先，请确保您已安装uv可执行文件。如果没有，您可以按照此处的说明进行安装。

  1. 打开位于以下位置的 Claude Desktop 配置文件：

    • 在 macOS 上： ~/Library/Application Support/Claude/claude_desktop_config.json

    • 在 Windows 上： %APPDATA%/Claude/claude_desktop_config.json

  2. 添加以下内容：

{
  "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\"}"
      }
    }
  }
}

更新环境变量以指向您自己的 Timeplus 服务。

  1. 重新启动 Claude Desktop 以应用更改。

您还可以尝试将此 MCP 服务器与其他 MCP 客户端（例如5ire）一起使用。

发展

  1. 在test-services目录中运行docker compose up -d启动 Timeplus Proton 服务器。你也可以通过curl https://install.timeplus.com/oss | sh下载，然后使用./proton server启动。

  2. 将以下变量添加到存储库根目录中的.env文件中。

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"}

  1. 运行uv sync安装依赖项。然后执行source .venv/bin/activate 。

  2. 为了方便测试，您可以运行mcp dev mcp_timeplus/mcp_server.py来启动 MCP 服务器。点击“连接”按钮将 UI 连接到 MCP 服务器，然后切换到“工具”选项卡运行可用的工具。

  3. 要构建 Docker 镜像，请运行docker build -t mcp_timeplus . 。

环境变量

以下环境变量用于配置 Timeplus 连接：

必需变量

  • TIMEPLUS_HOST ：您的 Timeplus 服务器的主机名

  • TIMEPLUS_USER ：用于身份验证的用户名

  • TIMEPLUS_PASSWORD ：身份验证的密码

可选变量

  • TIMEPLUS_PORT ：Timeplus 服务器的端口号

    • 默认值：如果启用 HTTPS， 8443 ；如果禁用， 8123

    • 通常不需要设置，除非使用非标准端口

  • TIMEPLUS_SECURE ：启用/禁用 HTTPS 连接

    • 默认值： "false"

    • 设置为"true"以实现安全连接

  • TIMEPLUS_VERIFY ：启用/禁用 SSL 证书验证

    • 默认值： "true"

    • 设置为"false"以禁用证书验证（不建议用于生产）

  • TIMEPLUS_CONNECT_TIMEOUT ：连接超时（秒）

    • 默认值： "30"

    • 如果遇到连接超时，请增加此值

  • TIMEPLUS_SEND_RECEIVE_TIMEOUT ：发送/接收超时（秒）

    • 默认值： "300"

    • 对于长时间运行的查询，请增加此值

  • TIMEPLUS_DATABASE ：默认使用的数据库

    • 默认值：无（使用服务器默认值）

    • 将其设置为自动连接到特定数据库

  • TIMEPLUS_READ_ONLY ：启用/禁用只读模式

    • 默认值： "true"

    • 设置为"false"以启用 DDL/DML

  • TIMEPLUS_KAFKA_CONFIG ：Kafka 配置的 JSON 字符串。请参考librdkafka 配置或以上述示例为参考。

Available Tools

7 tools
connect_to_apache_icebergC

Create a Timeplus database in iceberg type to connect to Iceberg

ParametersJSON Schema
NameRequiredDescriptionDefault
iceberg_dbYes
aws_account_idYes
s3_bucketYes
aws_regionNous-west-2
is_s3_table_bucketNo

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
NameRequiredDescriptionDefault
topicYes

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
NameRequiredDescriptionDefault
topicYes
message_countNo

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
NameRequiredDescriptionDefault

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
NameRequiredDescriptionDefault

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
NameRequiredDescriptionDefault
databaseNodefault
likeNo

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
NameRequiredDescriptionDefault
queryYes

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.

  1. 7 tool updates
    • 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
Deploy Server
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

C2.4/5.0

Scored across 7 tools

Disambiguation3/5

Most tools target distinct actions: listing databases, listing tables, running SQL, and connecting Iceberg are clearly separate. However, list_kafka_topics and explore_kafka_topic have overlapping territory around Kafka topics, and create_kafka_stream is adjacent to them; the empty descriptions worsen the ambiguity.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern in lowercase snake_case, such as list_databases, list_tables, and create_kafka_stream. The only slight deviation is connect_to_apache_iceberg, but it still follows the same verb-first convention.

Tool Count5/5

Seven tools is a well-scoped set for a Timeplus MCP server, covering database exploration, SQL execution, Kafka integration, and Iceberg connectivity without bloating the surface.

Completeness4/5

The toolset covers core querying, table/database listing, and Kafka stream ingestion plus Iceberg connection. Minor gaps exist around resource management (e.g., creating/dropping regular databases or streams), but the main read and integration workflows are supported.

Maintenance

ActivityInactive
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers

  • Kafka MCP Server

    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.
    17
    Apache 2.0

  • KafkaIQ

    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.
    -
  • Microsoft Fabric RTI MCP Server by microsoft

    Microsoft Fabric RTI MCPofficial

    microsoft
    A
    license
    B
    quality
    A
    maintenance
    Enables AI agents to interact with Microsoft Fabric Real-Time Intelligence services, allowing for seamless data querying, analysis, and streaming capabilities.
    39
    5,623 PyPI
    132
    MIT

Appeared in Searches