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): 表示するメッセージの数。デフォルトは 1。

  • create_kafka_stream

    • Timeplus でストリーミング ETL を設定し、Kafka メッセージをローカルに保存します。

    • 入力: topic (文字列): トピックの名前。

  • connect_to_apache_iceberg

    • Apache Icebergベースのデータベースに接続します。現在、この機能はTimeplus Enterpriseでのみ利用可能ですが、近日中にTimeplus Protonでも利用可能になる予定です。

    • 入力: iceberg_db (文字列): Iceberg データベースの名前。 aws_account_id (int): AWS アカウント ID (12 桁)。 s3_bucket (文字列): S3 バケット名。 aws_region (文字列): AWS リージョン。デフォルトは「us-west-2」。 is_s3_table_bucket (bool): S3 バケットが 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 サーバーを5ireなどの他の MCP クライアントで試すこともできます。

発達

  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"

    • DDL/DMLを有効にするには"false"に設定してください

  • 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