Skip to main content
Glama
enesjakozh
timeplus-io

mcp-timeplus

by timeplus-io
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

Servidor MCP de Timeplus

PyPI - Versión

Un servidor MCP para Timeplus.

Características

Indicaciones

  • generate_sql para brindarle a LLM más conocimientos sobre cómo consultar Timeplus a través de SQL

Herramientas

  • run_sql

    • Ejecute consultas SQL en su clúster Timeplus.

    • Entrada: sql (cadena): la consulta SQL a ejecutar.

    • De forma predeterminada, todas las consultas de Timeplus se ejecutan con readonly = 1 para garantizar su seguridad. Si desea ejecutar consultas DDL o DML, puede establecer la variable de entorno TIMEPLUS_READ_ONLY en false .

  • list_databases

    • Enumere todas las bases de datos en su clúster Timeplus.

  • list_tables

    • Enumerar todas las tablas de una base de datos.

    • Entrada: database (cadena): el nombre de la base de datos.

  • list_kafka_topics

    • Enumerar todos los temas en un clúster de Kafka

  • explore_kafka_topic

    • Mostrar algunos mensajes en el tema de Kafka

    • Entrada: topic (cadena): el nombre del tema. message_count (int): la cantidad de mensajes a mostrar, el valor predeterminado es 1.

  • create_kafka_stream

    • Configurar un ETL de transmisión en Timeplus para guardar los mensajes de Kafka localmente

    • Entrada: topic (cadena): el nombre del tema.

  • connect_to_apache_iceberg

    • Conéctese a una base de datos basada en Apache Iceberg. Actualmente, esto solo está disponible a través de Timeplus Enterprise y está previsto que esté disponible próximamente para Timeplus Proton.

    • Entrada: iceberg_db (cadena): el nombre de la base de datos Iceberg. aws_account_id (int): el ID de la cuenta de AWS (12 dígitos). s3_bucket (cadena): el nombre del bucket de S3. aws_region (cadena): la región de AWS, el valor predeterminado es "us-west-2". is_s3_table_bucket (bool): si el bucket de S3 es un bucket de tabla de S3, el valor predeterminado es Falso.

Related MCP server: Kafka MCP Server

Configuración

Primero, asegúrate de tener instalado el ejecutable uv . De lo contrario, puedes instalarlo siguiendo las instrucciones aquí .

  1. Abra el archivo de configuración de Claude Desktop ubicado en:

    • En macOS: ~/Library/Application Support/Claude/claude_desktop_config.json

    • En Windows: %APPDATA%/Claude/claude_desktop_config.json

  2. Añade lo siguiente:

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

Actualice las variables de entorno para que apunten a su propio servicio Timeplus.

  1. Reinicie Claude Desktop para aplicar los cambios.

También puedes probar este servidor MCP con otros clientes MCP, como 5ire .

Desarrollo

  1. En el directorio test-services ejecute docker compose up -d para iniciar un servidor Timeplus Proton. También puede descargarlo mediante curl https://install.timeplus.com/oss | sh y luego iniciarlo con ./proton server .

  2. Agregue las siguientes variables a un archivo .env en la raíz del repositorio.

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. Ejecute uv sync para instalar las dependencias. Luego, ejecute source .venv/bin/activate .

  2. Para facilitar las pruebas, puede ejecutar mcp dev mcp_timeplus/mcp_server.py para iniciar el servidor MCP. Haga clic en el botón "Conectar" para conectar la interfaz de usuario con el servidor MCP y, a continuación, vaya a la pestaña "Herramientas" para ejecutar las herramientas disponibles.

  3. Para crear la imagen de Docker, ejecute docker build -t mcp_timeplus . .

Variables de entorno

Las siguientes variables de entorno se utilizan para configurar la conexión Timeplus:

Variables requeridas

  • TIMEPLUS_HOST : El nombre de host de su servidor Timeplus

  • TIMEPLUS_USER : El nombre de usuario para la autenticación

  • TIMEPLUS_PASSWORD : La contraseña para la autenticación

Variables opcionales

  • TIMEPLUS_PORT : El número de puerto de su servidor Timeplus

    • Predeterminado: 8443 si HTTPS está habilitado, 8123 si está deshabilitado

    • Generalmente no es necesario configurarlo a menos que se utilice un puerto no estándar

  • TIMEPLUS_SECURE : Habilitar/deshabilitar la conexión HTTPS

    • Predeterminado: "false"

    • Establezca en "true" para conexiones seguras

  • TIMEPLUS_VERIFY : Habilitar/deshabilitar la verificación del certificado SSL

    • Valor predeterminado: "true"

    • Establezca en "false" para deshabilitar la verificación del certificado (no recomendado para producción)

  • TIMEPLUS_CONNECT_TIMEOUT : Tiempo de espera de conexión en segundos

    • Valor predeterminado: "30"

    • Aumente este valor si experimenta tiempos de espera de conexión

  • TIMEPLUS_SEND_RECEIVE_TIMEOUT : Tiempo de espera de envío/recepción en segundos

    • Valor predeterminado: "300"

    • Aumente este valor para consultas de larga duración

  • TIMEPLUS_DATABASE : Base de datos predeterminada a utilizar

    • Predeterminado: Ninguno (usa el valor predeterminado del servidor)

    • Configure esto para conectarse automáticamente a una base de datos específica

  • TIMEPLUS_READ_ONLY : Habilitar/deshabilitar el modo de solo lectura

    • Valor predeterminado: "true"

    • Establezca en "false" para habilitar DDL/DML

  • TIMEPLUS_KAFKA_CONFIG : Cadena JSON para la configuración de Kafka. Consulte la configuración de librdkafka o utilice el ejemplo anterior como referencia.

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