Skip to main content
Glama
deenesjakoruzh
idoru

InfluxDB MCP Server

by idoru
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

Servidor MCP de InfluxDB

insignia de herrería

Un servidor de Protocolo de Contexto de Modelo (MCP) que expone el acceso a una instancia de InfluxDB mediante la API OSS de InfluxDB v2. Desarrollado principalmente con Claude Code.

Características

Este servidor MCP proporciona:

  • Recursos : Acceso a datos de organización, grupo y medición

  • Herramientas : escribir datos, ejecutar consultas y administrar objetos de base de datos

  • Indicaciones : Plantillas para consultas Flux comunes y formato de protocolo de línea

Related MCP server: InfluxDB OSS API MCP Server

Recursos

El servidor expone los siguientes recursos:

  1. Lista de organizaciones : influxdb://orgs

    • Muestra todas las organizaciones en la instancia de InfluxDB

  2. Lista de deseos : influxdb://buckets

    • Muestra todos los depósitos con sus metadatos

  3. Medidas del cubo : influxdb://bucket/{bucketName}/measurements

    • Enumera todas las mediciones dentro de un grupo específico

  4. Datos de consulta : influxdb://query/{orgName}/{fluxQuery}

    • Ejecuta una consulta Flux y devuelve resultados como un recurso

Herramientas

El servidor proporciona estas herramientas:

  1. write-data : escribe datos de series temporales en formato de protocolo de línea

    • Parámetros: organización, contenedor, datos, precisión (opcional)

  2. query-data : Ejecutar consultas Flux

    • Parámetros: org, consulta

  3. create-bucket : Crea un nuevo bucket

    • Parámetros: nombre, orgID, retainPeriodSeconds (opcional)

  4. create-org : Crea una nueva organización

    • Parámetros: nombre, descripción (opcional)

Indicaciones

El servidor ofrece estas plantillas de indicaciones:

  1. flux-query-examples : Ejemplos comunes de consultas Flux

  2. line-protocol-guide : Guía del formato del protocolo de línea de InfluxDB

Configuración

El servidor requiere estas variables de entorno:

  • INFLUXDB_TOKEN (obligatorio): token de autenticación para la API de InfluxDB

  • INFLUXDB_URL (opcional): URL de la instancia de InfluxDB (el valor predeterminado es http://localhost:8086 )

  • INFLUXDB_ORG (opcional): Nombre de la organización predeterminado para ciertas operaciones

Instalación

Instalación mediante herrería

Para instalar InfluxDB MCP Server para Claude Desktop automáticamente a través de Smithery :

npx -y @smithery/cli install @idoru/influxdb-mcp-server --client claude

Opción 1: Ejecutar con npx (recomendado)

# Run directly with npx
INFLUXDB_TOKEN=your_token npx influxdb-mcp-server

Opción 2: Instalar globalmente

# Install globally
npm install -g influxdb-mcp-server

# Run the server
INFLUXDB_TOKEN=your_token influxdb-mcp-server

Opción 3: Desde la fuente

# Clone the repository
git clone https://github.com/idoru/influxdb-mcp-server.git
cd influxdb-mcp-server

# Install dependencies
npm install

# Run the server
INFLUXDB_TOKEN=your_token npm start

Integración con Claude para escritorio

Agregue el servidor a su claude_desktop_config.json :

Usando npx (recomendado)

{
  "mcpServers": {
    "influxdb": {
      "command": "npx",
      "args": ["influxdb-mcp-server"],
      "env": {
        "INFLUXDB_TOKEN": "your_token",
        "INFLUXDB_URL": "http://localhost:8086",
        "INFLUXDB_ORG": "your_org"
      }
    }
  }
}

Si se instala localmente

{
  "mcpServers": {
    "influxdb": {
      "command": "node",
      "args": ["/path/to/influxdb-mcp-server/src/index.js"],
      "env": {
        "INFLUXDB_TOKEN": "your_token",
        "INFLUXDB_URL": "http://localhost:8086",
        "INFLUXDB_ORG": "your_org"
      }
    }
  }
}

Estructura del código

El código del servidor está organizado en una estructura modular:

  • src/

    • index.js - Punto de entrada del servidor principal

    • config/ - Archivos relacionados con la configuración

      • env.js - Manejo de variables de entorno

    • utils/ - Funciones de utilidad

      • influxClient.js - Cliente de la API de InfluxDB

      • loggerConfig.js - Configuración del registrador de la consola

    • handlers/ - Manipuladores de recursos y herramientas

      • organizationsHandler.js - Listado de organizaciones

      • bucketsHandler.js - Listado de buckets

      • measurementsHandler.js - Listado de mediciones

      • queryHandler.js - Ejecución de consultas

      • writeDataTool.js - Herramienta de escritura de datos

      • queryDataTool.js - Herramienta de consulta

      • createBucketTool.js - Herramienta de creación de buckets

      • createOrgTool.js - Herramienta de creación de organizaciones

    • prompts/ - Plantillas de indicaciones

      • fluxQueryExamplesPrompt.js - Ejemplos de consultas Flux

      • lineProtocolGuidePrompt.js - Guía del protocolo de línea

Esta estructura permite un mejor mantenimiento, pruebas más sencillas y una separación más clara de las preocupaciones.

Pruebas

El repositorio incluye pruebas de integración integrales que:

  • Ponga en marcha un contenedor Docker con InfluxDB

  • Rellénelo con datos de muestra

  • Pruebe todas las funciones del servidor MCP

Para ejecutar las pruebas:

npm test

Licencia

Instituto Tecnológico de Massachusetts (MIT)

Available Tools

4 tools
create-bucketB

Provision a new bucket under an organization so that subsequent write-data calls have a destination.

ParametersJSON Schema
NameRequiredDescriptionDefault
nameYesFriendly bucket name. Follow InfluxDB naming rules (alphanumeric, dashes, underscores).
orgIDYesOrganization ID (UUID) that will own the bucket. Retrieve it from the organizations resource or create-org output.
retentionPeriodSecondsNoOptional retention duration expressed in seconds. Omit for infinite retention.

TDQS

B3.3/5.0
Behavior2/5

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

With no annotations provided, the description carries the full burden of behavioral transparency. It does not disclose important traits like permissions required, uniqueness constraints, idempotency, error conditions, or side effects. This is insufficient for an agent to safely invoke the tool.

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 sentence, concise and front-loaded. It conveys the essential purpose efficiently, though it could include more detail 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?

Given the three parameters and no output schema, the description lacks essential context such as uniqueness constraints for bucket names, validity of orgID, potential errors, and return values. This leaves gaps for the agent.

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

Parameters3/5

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

Schema coverage is 100%, so the baseline is 3. The description adds minor context by linking the bucket to subsequent write-data calls, but does not significantly enhance understanding beyond the schema descriptions.

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 tool provisions a new bucket under an organization, with a specific verb and resource. It also ties to sibling tools by explaining that this bucket serves as a destination for write-data calls, distinguishing it from create-org, query-data, and write-data.

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?

The description implies the tool should be used before write-data to create a destination, but does not explicitly state when not to use it or provide alternatives. Usage guidance is present but minimal.

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

create-orgA

Create a brand-new organization to isolate users or projects before generating buckets and tokens.

ParametersJSON Schema
NameRequiredDescriptionDefault
nameYesDisplay name for the organization as it should appear in InfluxDB Cloud/OSS.
descriptionNoOptional free-form description that helps humans understand why the org exists.

TDQS

A3.7/5.0
Behavior2/5

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

With no annotations provided, the description carries full burden. It only states the creation action but does not disclose any side effects, required permissions, or behavioral constraints, leaving significant gaps for a mutation tool.

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?

The description is a single, well-structured sentence that front-loads the action and purpose. No extraneous words; every part earns its place.

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

Completeness3/5

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

For a simple creation tool with two parameters and no output schema, the description provides the essential purpose but lacks details on return values or post-creation behavior, making it adequate but not fully complete.

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

Parameters3/5

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

Schema description coverage is 100% (both name and description are documented in the schema). The tool description adds no extra meaning beyond what the schema already provides, so baseline score of 3 is appropriate.

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 (create), the resource (organization), and the purpose (isolate users/projects as a prerequisite for buckets/tokens). It distinguishes from siblings like create-bucket and query-data.

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

Usage Guidelines4/5

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

The phrase 'before generating buckets and tokens' effectively indicates when to use this tool as a prerequisite step. While it lacks explicit exclusions or comparisons, the context is sufficient for an AI agent.

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

query-dataA

Execute a Flux query inside an organization to inspect measurement schemas, run aggregations, or validate recently written data.

ParametersJSON Schema
NameRequiredDescriptionDefault
orgYesOrganization whose buckets the query should target (exact name, not ID).
queryYesFlux query text. Multi-line strings are supported; results are returned as annotated CSV for easy parsing.

TDQS

A3.8/5.0
Behavior3/5

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

Since no annotations are provided, the description must convey behavior. It indicates a read operation (query) but does not mention permissions, rate limits, or output format (though schema mentions CSV). The description adds moderate behavioral context but lacks depth.

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, reasonably concise sentence that conveys the core purpose. It could be slightly tighter, but no unnecessary words.

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

Completeness3/5

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

For a simple query tool with two parameters and no output schema, the description covers purpose and usage scenarios. It omits potential guidance on query performance, timeouts, or security, making it adequate but not comprehensive.

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

Parameters3/5

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

Schema coverage is 100% with clear descriptions for both parameters. The description adds no new parameter-specific meaning beyond the use cases. Baseline score of 3 is appropriate.

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?

Description clearly states the verb 'execute' and the resource 'Flux query inside an organization', with specific example use cases (inspect schemas, run aggregations, validate data). It effectively distinguishes from sibling tools that create or write.

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

Usage Guidelines4/5

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

The description provides context by listing example scenarios (inspect schemas, run aggregations, validate data), which implies when to use. However, it does not explicitly contrast with siblings or state when not to use.

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

write-dataA

Stream newline-delimited line protocol records into a bucket. Use this after composing measurements so the LLM can insert real telemetry, optionally controlling timestamp precision.

ParametersJSON Schema
NameRequiredDescriptionDefault
orgYesHuman-readable organization name that owns the destination bucket (the same value returned by the orgs resource).
bucketYesBucket name to receive the points. Make sure it already exists or call create-bucket first.
dataYesPayload containing one or more line protocol lines (measurements, tags, fields, timestamps) separated by newlines.
precisionNoOptional timestamp precision. Provide it only when the line protocol omits unit suffix context; defaults to nanoseconds.

TDQS

A3.6/5.0
Behavior2/5

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

With no annotations provided, the description carries full responsibility for behavioral disclosure. It only mentions streaming and insertion, but does not explain whether the operation is append-only or destructive, what happens to existing data, required permissions, rate limits, or error conditions. For a write tool, these omissions are significant.

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?

The description consists of two concise sentences. It immediately states the core action and then adds the use case and optional control. No redundant or unnecessary words.

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?

Given the lack of annotations and output schema, the description should cover more contextual details. It does not describe the return value (e.g., success indicator, count of points written), error handling, or prerequisites like bucket existence (though hinted in schema). The tool's complexity is moderate, but the description omits essential information for an agent to use it correctly.

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

Parameters3/5

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

All four parameters have descriptions in the input schema (100% coverage). The tool description adds minimal new meaning beyond the schema, only noting that precision is optional and controls timestamp precision. The schema already provides adequate descriptions for org, bucket, data, and precision. Baseline score of 3 is appropriate.

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: streaming line protocol records into a bucket. It specifies the format (newline-delimited) and the use case (after composing measurements for telemetry insertion). It distinguishes well from sibling tools like create-bucket (bucket creation) and query-data (reading data).

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

Usage Guidelines4/5

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

The description provides context: 'Use this after composing measurements so the LLM can insert real telemetry'. This implies the tool is for writing data after preparation. It does not explicitly state when not to use it or mention alternatives, but the sibling tools are clearly different in purpose. The schema parameter description for 'bucket' hints at a prerequisite (bucket must exist), but the main description lacks explicit exclusions.

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. 4 tool updatesv0.2.0
    • Changedcreate-bucket3 fields changed
      • changedInput schema / properties / name / description
        Previous value: -"The bucket name"New value: +"Friendly bucket name. Follow InfluxDB naming rules (alphanumeric, dashes, underscores)."
      • changedInput schema / properties / orgID / description
        Previous value: -"The organization ID"New value: +"Organization ID (UUID) that will own the bucket. Retrieve it from the organizations resource or create-org output."
      • changedInput schema / properties / retentionPeriodSeconds / description
        Previous value: -"Retention period in seconds (optional)"New value: +"Optional retention duration expressed in seconds. Omit for infinite retention."
    • Changedcreate-org2 fields changed
      • changedInput schema / properties / description / description
        Previous value: -"Organization description (optional)"New value: +"Optional free-form description that helps humans understand why the org exists."
      • changedInput schema / properties / name / description
        Previous value: -"The organization name"New value: +"Display name for the organization as it should appear in InfluxDB Cloud/OSS."
    • Changedquery-data2 fields changed
      • changedInput schema / properties / org / description
        Previous value: -"The organization name"New value: +"Organization whose buckets the query should target (exact name, not ID)."
      • changedInput schema / properties / query / description
        Previous value: -"Flux query string"New value: +"Flux query text. Multi-line strings are supported; results are returned as annotated CSV for easy parsing."
    • Changedwrite-data4 fields changed
      • changedInput schema / properties / bucket / description
        Previous value: -"The bucket name"New value: +"Bucket name to receive the points. Make sure it already exists or call create-bucket first."
      • changedInput schema / properties / data / description
        Previous value: -"Data in InfluxDB line protocol format"New value: +"Payload containing one or more line protocol lines (measurements, tags, fields, timestamps) separated by newlines."
      • changedInput schema / properties / org / description
        Previous value: -"The organization name"New value: +"Human-readable organization name that owns the destination bucket (the same value returned by the orgs resource)."
      • changedInput schema / properties / precision / description
        Previous value: -"Timestamp precision (ns, us, ms, s)"New value: +"Optional timestamp precision. Provide it only when the line protocol omits unit suffix context; defaults to nanoseconds."
  2. 4 tool updatesv1.0.0
    • First observedcreate-bucket
    • First observedcreate-org
    • First observedquery-data
    • First observedwrite-data
Deploy Server
Shareable, User-Owned Context BackendPeople, applications, and agents read, write, and coordinate together in one context lake. Reach it over MCP, a CLI, a Python SDK, or REST.fulcradynamics.comAd

TDQS

A3.6/5.0

Scored across 4 tools

Disambiguation5/5

Each tool targets a distinct operation: organization creation, bucket creation, data writing, and querying. There is no overlap in functionality.

Naming Consistency5/5

All tool names follow a consistent verb-noun pattern with hyphens (create-bucket, create-org, query-data, write-data).

Tool Count4/5

With 4 tools, the server is well-scoped for basic InfluxDB operations, though it is on the smaller side.

Completeness2/5

The set lacks read, update, and delete operations for organizations and buckets, which are common needs when managing an InfluxDB instance. This could lead to agent failures.

Maintenance

ActivityInactive
ResponsivenessUnresponsive

Resources

Related MCP Connectors

Related MCP Servers

  • InfluxDB MCP Server

    m4tyn0
    F
    license
    Not graded
    quality
    D
    maintenance
    A Model Context Protocol server that provides secure, read-only access to time-series data stored in InfluxDB 1.8 via JWT authentication.
    4
    -

  • InfluxDB-v1-MCP

    GreenScreen410
    A
    license
    Not graded
    quality
    D
    maintenance
    InfluxDB-v1-MCP is a powerful Model Context Protocol (MCP) interface specifically designed for InfluxDB v1.x, enabling AI assistants to intelligently manage and query time-series databases.
    Apache 2.0