Skip to main content
Glama
deenesjakoruzh
idoru

InfluxDB MCP Server

by idoru
OverviewSchemaRelated ServersScoreDiscussions
JavaScript
Remote

InfluxDB v2 MCP Server

Trust Score

A Model Context Protocol (MCP) server that exposes access to an InfluxDB v2 instance using the InfluxDB OSS API v2. Mostly built with Claude Code.

Features

This MCP server provides:

  • Resources: Access to organization, bucket, and measurement data

  • Tools: Write data, execute queries, and manage database objects

  • Prompts: Templates for common Flux queries and Line Protocol format

Related MCP server: InfluxDB OSS API MCP Server

Resources

The server exposes the following resources:

  1. Organizations List: influxdb://orgs

    • Displays all organizations in the InfluxDB instance

  2. Buckets List: influxdb://buckets

    • Shows all buckets with their metadata

  3. Bucket Measurements: influxdb://bucket/{bucketName}/measurements

    • Lists all measurements within a specified bucket

  4. Query Data: influxdb://query/{orgName}/{fluxQuery}

    • Executes a Flux query and returns results as a resource

Tools

The server provides these tools:

  1. write-data: Write time-series data in line protocol format

    • Parameters: org, bucket, data, precision (optional)

  2. query-data: Execute Flux queries

    • Parameters: org, query

  3. create-bucket: Create a new bucket

    • Parameters: name, orgID, retentionPeriodSeconds (optional)

  4. create-org: Create a new organization

    • Parameters: name, description (optional)

Prompts

The server offers these prompt templates:

  1. flux-query-examples: Common Flux query examples

  2. line-protocol-guide: Guide to InfluxDB line protocol format

Configuration

The server requires these environment variables:

  • INFLUXDB_TOKEN (required): Authentication token for the InfluxDB API

  • INFLUXDB_URL (optional): URL of the InfluxDB instance (defaults to http://localhost:8086)

  • INFLUXDB_ORG (optional): Default organization name for certain operations

Installation

Installing via Smithery

To install InfluxDB MCP Server for Claude Desktop automatically via Smithery:

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

Option 1: Run with npx (recommended)

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

Option 2: Install globally

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

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

Option 3: From source

# 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

influxdb-mcp-server uses stdio transport by default. You can explicitly request it with --stdio, or start the server with Streamable HTTP transport by providing the --http option with an optional port number (defaults to 3000). This mode uses an internal Express.js server:

# Start with Streamable HTTP transport on default port 3000
INFLUXDB_TOKEN=your_token npm start -- --http

# Start with Streamable HTTP transport on a specific port
INFLUXDB_TOKEN=your_token npm start -- --http 8080

If you installed globally or are using npx, you can run:

INFLUXDB_TOKEN=your_token influxdb-mcp-server --http
# or explicitly force stdio
INFLUXDB_TOKEN=your_token influxdb-mcp-server --stdio
# or
INFLUXDB_TOKEN=your_token influxdb-mcp-server --http 8080

Integration with Claude for Desktop

Add the server to your claude_desktop_config.json:

Using npx (recommended)

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

If installed locally

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

Code Structure

The server code is organized into a modular structure:

  • src/

    • index.js - Main server entry point

    • config/ - Configuration related files

      • env.js - Environment variable handling

    • utils/ - Utility functions

      • influxClient.js - InfluxDB API client

      • loggerConfig.js - Console logger configuration

    • handlers/ - Resource and tool handlers

      • organizationsHandler.js - Organizations listing

      • bucketsHandler.js - Buckets listing

      • measurementsHandler.js - Measurements listing

      • queryHandler.js - Query execution

      • writeDataTool.js - Data write tool

      • queryDataTool.js - Query tool

      • createBucketTool.js - Bucket creation tool

      • createOrgTool.js - Organization creation tool

    • prompts/ - Prompt templates

      • fluxQueryExamplesPrompt.js - Flux query examples

      • lineProtocolGuidePrompt.js - Line protocol guide

This structure allows for better maintainability, easier testing, and clearer separation of concerns.

Testing

The repository includes comprehensive integration tests that:

  • Spin up a Docker container with InfluxDB

  • Populate it with sample data

  • Test all MCP server functionality

To run the tests:

npm test

License

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. Dates show when Glama detected each change.

  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
Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.6/5.0
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
ResponsivenessSyncing

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

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

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/idoru/influxdb-mcp-server'

If you have feedback or need assistance with the MCP directory API, please join our Discord server