Skip to main content
Glama
deenesjakoruzh
idoru

InfluxDB MCP Server

by idoru
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

InfluxDB MCP 서버

대장간 배지

InfluxDB OSS API v2를 사용하여 InfluxDB 인스턴스에 대한 액세스를 제공하는 모델 컨텍스트 프로토콜(MCP) 서버입니다. 대부분 Claude Code로 구축되었습니다.

특징

이 MCP 서버는 다음을 제공합니다.

  • 리소스 : 조직, 버킷 및 측정 데이터에 대한 액세스

  • 도구 : 데이터 쓰기, 쿼리 실행, 데이터베이스 객체 관리

  • 프롬프트 : 일반적인 Flux 쿼리 및 라인 프로토콜 형식에 대한 템플릿

Related MCP server: InfluxDB OSS API MCP Server

자원

서버는 다음과 같은 리소스를 제공합니다.

  1. 조직 목록 : influxdb://orgs

    • InfluxDB 인스턴스의 모든 조직을 표시합니다.

  2. 버킷 리스트 : influxdb://buckets

    • 모든 버킷을 메타데이터와 함께 표시합니다.

  3. 버킷 측정 : influxdb://bucket/{bucketName}/measurements

    • 지정된 버킷 내의 모든 측정값을 나열합니다.

  4. 쿼리 데이터 : influxdb://query/{orgName}/{fluxQuery}

    • Flux 쿼리를 실행하고 결과를 리소스로 반환합니다.

도구

서버는 다음과 같은 도구를 제공합니다.

  1. write-data : 라인 프로토콜 형식으로 시계열 데이터를 씁니다.

    • 매개변수: org, bucket, data, precision(선택 사항)

  2. query-data : Flux 쿼리 실행

    • 매개변수: org, 쿼리

  3. create-bucket : 새로운 버킷을 생성합니다

    • 매개변수: name, orgID, retentionPeriodSeconds(선택 사항)

  4. create-org : 새로운 조직을 만듭니다

    • 매개변수: 이름, 설명(선택 사항)

프롬프트

서버는 다음과 같은 프롬프트 템플릿을 제공합니다.

  1. flux-query-examples : 일반적인 Flux 쿼리 예시

  2. line-protocol-guide : InfluxDB 라인 프로토콜 형식 가이드

구성

서버에는 다음과 같은 환경 변수가 필요합니다.

  • INFLUXDB_TOKEN (필수): InfluxDB API에 대한 인증 토큰

  • INFLUXDB_URL (선택 사항): InfluxDB 인스턴스의 URL(기본값은 http://localhost:8086 )

  • INFLUXDB_ORG (선택 사항): 특정 작업에 대한 기본 조직 이름

설치

Smithery를 통해 설치

Smithery를 통해 Claude Desktop에 InfluxDB MCP 서버를 자동으로 설치하려면:

지엑스피1

옵션 1: npx로 실행(권장)

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

옵션 2: 글로벌 설치

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

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

옵션 3: 소스에서

# 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

데스크톱용 Claude와 통합

claude_desktop_config.json 에 서버를 추가합니다.

npx 사용(권장)

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

로컬로 설치된 경우

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

코드 구조

서버 코드는 모듈형 구조로 구성됩니다.

  • src/

    • index.js - 메인 서버 진입점

    • config/ - 구성 관련 파일

      • env.js - 환경 변수 처리

    • utils/ - 유틸리티 함수

      • influxClient.js - InfluxDB API 클라이언트

      • loggerConfig.js - 콘솔 로거 구성

    • handlers/ - 리소스 및 도구 핸들러

      • organizationsHandler.js - 조직 목록

      • bucketsHandler.js - 버킷 목록

      • measurementsHandler.js - 측정 목록

      • queryHandler.js - 쿼리 실행

      • writeDataTool.js - 데이터 쓰기 도구

      • queryDataTool.js - 쿼리 도구

      • createBucketTool.js - 버킷 생성 도구

      • createOrgTool.js - 조직 생성 도구

    • prompts/ - 프롬프트 템플릿

      • fluxQueryExamplesPrompt.js - Flux 쿼리 예제

      • lineProtocolGuidePrompt.js - 라인 프로토콜 가이드

이러한 구조는 더 나은 유지 관리, 더 쉬운 테스트, 그리고 더 명확한 관심사 분리를 가능하게 합니다.

테스트

저장소에는 다음과 같은 포괄적인 통합 테스트가 포함되어 있습니다.

  • InfluxDB로 Docker 컨테이너를 시작하세요

  • 샘플 데이터로 채우세요

  • 모든 MCP 서버 기능 테스트

테스트를 실행하려면:

npm test

특허

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