Skip to main content
Glama
enesjakozh
timeplus-io

mcp-timeplus

by timeplus-io
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

타임플러스 MCP 서버

PyPI - 버전

Timeplus의 MCP 서버.

특징

프롬프트

  • SQL을 통해 Timeplus를 쿼리하는 방법에 대한 더 많은 지식을 LLM에 제공하기 위한 generate_sql

도구

  • 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 (정수): 표시할 메시지 수이며 기본값은 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 지역이며 기본값은 "us-west-2"입니다. is_s3_table_bucket (부울): 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. 다음을 추가합니다.

지엑스피1

환경 변수를 업데이트하여 사용자의 Timeplus 서비스를 가리키도록 합니다.

  1. 변경 사항을 적용하려면 Claude Desktop을 다시 시작하세요.

5ire 와 같은 다른 MCP 클라이언트와 함께 이 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