Skip to main content
Glama
Sign In
deenesjakoruzh
InfluxDB MCP Server

InfluxDB MCP Server

by idoru
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

InfluxDB v2 MCP Server

LightNow

Listed on Spark Install via Spark

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 (uses INFLUXDB_ORG)

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

    • Executes a Flux query and returns results as JSON (headers and one record per row, across all result tables)

Template variables (bucketName, orgName, fluxQuery) must be percent-encoded, e.g. with encodeURIComponent, so names containing spaces or / and multi-line queries survive the URI.

Tools

The server provides these tools:

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

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

    • org and bucket are optional when INFLUXDB_ORG / INFLUXDB_BUCKET are set, and fall back to those values

  2. query-data: Execute Flux queries

    • Parameters: org, query

    • org is optional when INFLUXDB_ORG is set, and falls back to that value

  3. create-bucket: Create a new bucket

    • Parameters: name, orgID, retentionPeriodSeconds (optional, whole seconds; omit or pass 0 for infinite retention)

  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. When set, org becomes optional on the write-data and query-data tools

  • INFLUXDB_BUCKET (optional): Default bucket name. When set, bucket becomes optional on the write-data tool

  • DEBUG (optional): Set to mcp:* to log every MCP message to stderr. This includes query text and written data, so leave it off in production

The following variables apply only to the Streamable HTTP transport (see HTTP transport security):

  • MCP_HTTP_HOST (optional): Interface to listen on (defaults to 127.0.0.1; same as --host)

  • MCP_AUTH_TOKEN (optional): When set, every request must send Authorization: Bearer <token>. Required to listen on a non-loopback interface

  • MCP_ALLOWED_HOSTS (optional): Comma-separated hostnames (ports are ignored) accepted in the Host header. Defaults to localhost,127.0.0.1,[::1] plus the bind address on loopback; unset means no Host check on other interfaces

  • MCP_HTTP_ALLOW_UNAUTHENTICATED (optional): Set to true to listen on a non-loopback interface without MCP_AUTH_TOKEN, e.g. behind a reverse proxy that authenticates for you

  • MCP_HTTP_BODY_LIMIT (optional): Maximum request body size (defaults to 4mb; accepts b, kb or mb suffixes). Raise it for very large write-data batches

Requests to InfluxDB time out after 10 seconds (60 seconds for queries, 30 seconds for writes), including the time spent reading the response.

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

Node.js 20 or later is required.

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 that listens on 127.0.0.1 unless --host is given:

# 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

HTTP transport security

Anyone who can reach the HTTP endpoint can read and write InfluxDB with the server's INFLUXDB_TOKEN, so the HTTP transport is locked down by default:

  • It listens on 127.0.0.1 only.

  • On loopback it rejects requests whose Host header is not localhost, 127.0.0.1 or [::1], which blocks DNS rebinding attacks from websites open in your browser.

  • It refuses to listen on any other interface unless MCP_AUTH_TOKEN is set (or MCP_HTTP_ALLOW_UNAUTHENTICATED=true).

To expose the server on your network, or from a container, require a bearer token:

INFLUXDB_TOKEN=your_token MCP_AUTH_TOKEN="$(openssl rand -hex 32)" \
  influxdb-mcp-server --http 3000 --host 0.0.0.0

Clients then send Authorization: Bearer <MCP_AUTH_TOKEN> with each request. Set MCP_ALLOWED_HOSTS to the hostnames clients use to reach the server for additional DNS rebinding protection. Prefer terminating TLS in front of the server when it is reachable beyond your machine.

Docker

The image runs as the unprivileged node user and uses stdio by default:

docker build -t influxdb-mcp-server .
docker run --rm -i -e INFLUXDB_TOKEN=your_token -e INFLUXDB_URL=http://host.docker.internal:8086 influxdb-mcp-server

# Streamable HTTP inside a container must bind 0.0.0.0, so it needs a token
docker run --rm -p 127.0.0.1:3000:3000 -e INFLUXDB_TOKEN=your_token -e MCP_AUTH_TOKEN=your_mcp_token \
  influxdb-mcp-server --http 3000 --host 0.0.0.0

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",
        "INFLUXDB_BUCKET": "your_bucket"
      }
    }
  }
}

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",
        "INFLUXDB_BUCKET": "your_bucket"
      }
    }
  }
}

Code Structure

The server code is organized into a modular structure:

  • src/

    • index.js - CLI entry point (argument parsing and transport selection)

    • server.js - MCP server factory registering resources, tools and prompts

    • config/ - Configuration related files

      • env.js - Environment variable handling

      • http.js - HTTP transport options and safety checks

    • http/ - Streamable HTTP transport

      • app.js - Express app (Host validation, bearer auth, body limits)

    • utils/ - Utility functions

      • influxClient.js - InfluxDB API client with request timeouts

      • csv.js - Flux CSV response parser

      • flux.js - Flux string escaping and URI parameter decoding

      • loggerConfig.js - Console logger configuration and DEBUG tracing

      • traceTransport.js - MCP message tracing for DEBUG=mcp:*

    • 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 tests that:

  • Spin up a Docker container with InfluxDB

  • Populate it with sample data

  • Test all MCP server functionality

  • Exercise the HTTP transport's Host validation, authentication and limits, and the CSV and Flux helpers, without Docker

To run the tests:

npm test

License

MIT

Available Tools

4 tools
create-bucketA

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

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 whole seconds. Omit (or pass 0) for infinite retention.

TDQS

A3.5/5.0
Behavior2/5

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

No annotations are provided, so the description carries the full behavioral burden, yet it discloses nothing about whether creation is idempotent, what happens when the name collides, required permissions, or what the response contains. For a mutation tool with zero annotation coverage this is a significant gap.

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?

A single front-loaded sentence with zero filler, stating the action, scope, and downstream purpose in order of importance.

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?

With only three parameters and full schema coverage, the input side is well served, and the purpose is clear. However, with no annotations and no output schema, the description should say more about mutation semantics (idempotency, conflicts, auth) to be truly 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%, so all three parameters (name, orgID, retentionPeriodSeconds) are already documented in the schema. The description adds no parameter-level meaning such as default retention behavior or naming constraints beyond what the schema states, so the baseline 3 applies.

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?

States a specific verb and resource ('Provision a new bucket') and scopes it to an organization, plus ties it to the write-data sibling as the downstream consumer. It is clearly distinguishable from create-org and query-data, though it never explicitly contrasts itself with them.

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 'so that subsequent write-data calls have a destination' gives a clear precondition: create this before writing data. It implies the context of use well but offers no explicit exclusions or alternative paths (e.g., what to do if a bucket already exists).

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

create-orgB

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

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

B3.2/5.0
Behavior2/5

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

No annotations are provided, so the description carries the full behavioral burden. Beyond 'brand-new' implying a mutation, it says nothing about permissions required, whether the call is idempotent, what happens on duplicate names, or what the response contains — significant gaps for a create operation.

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?

A single front-loaded sentence with no filler. It is efficient, though its brevity is partly why behavioral gaps remain rather than a model of well-packed information.

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?

Parameters are fully covered by the schema and there is no output schema to explain, but as an unannotated mutation tool the description should say more about side effects, required auth, and what is returned. It is minimally adequate rather than 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 coverage is 100% with only two well-documented parameters, so the schema already explains both 'name' and 'description'. The description adds no additional meaning about parameter formatting or defaults, so the baseline 3 applies.

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?

States a specific verb and resource ('Create a brand-new organization') and adds the reason for doing so (isolating users/projects). It does not explicitly name the sibling tools it differs from, but the mention of buckets and tokens makes the relationship to create-bucket clear enough.

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?

'...before generating buckets and tokens' gives a sequencing hint that this is a prerequisite step in a workflow. However, there is no explicit when-to-use/when-not guidance, no statement about what to do if an org already exists, and no alternative tools named.

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. Default org: "my-organization".

NameRequiredDescriptionDefault
orgNoOrganization whose buckets the query should target (exact name, not ID). Defaults to "my-organization" if omitted.
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?

No annotations are provided, so the description carries the full behavioral burden. It implies read-oriented use through verbs like "inspect" and "validate" and discloses the default organization, but it does not explicitly confirm read-only behavior, permissions requirements, side-effect boundaries, or error behavior for Flux queries.

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 two tight sentences, front-loads the core action and use cases, and includes the default organization without unnecessary detail. Every sentence contributes relevant information.

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 simple two-parameter schema and absence of an output schema, the description covers the tool's purpose and default org well. It could more explicitly mention result format or permission expectations, but it is largely complete for an agent to select and invoke the tool.

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%, so both the org and query parameters are already documented in the input schema. The description reinforces the default org value but adds no meaningful syntax, constraints, or semantics beyond what the schema already provides, making the baseline 3 appropriate.

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 states a specific verb and resource ("Execute a Flux query") and lists concrete use cases: inspecting measurement schemas, running aggregations, and validating recently written data. It is clearly a query/read tool, distinct from the sibling create-bucket, write-data, and create-org tools, though it does not explicitly name or contrast those alternatives.

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 clear usage contexts: inspect schemas, run aggregations, or validate data. It does not state when not to use the tool or explicitly compare it to alternatives, but the intended scenarios are sufficiently clear for an agent.

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

write-dataB

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. Default org: "my-organization".

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

TDQS

B3.2/5.0
Behavior2/5

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

No annotations, so the description carries the full burden. It conveys that this is a write/ingest path but says nothing about duplicate handling, overwrite semantics, partial-write behavior, batch size limits, or auth requirements — all material for a telemetry ingestion call.

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?

Front-loaded with the core action in the first sentence, followed by sequential guidance. The trailing 'Default org: "my-organization"' repeats the schema and is the one non-earning sentence.

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?

Parameters are fully covered by the schema and the purpose/sequencing is stated, but for a write tool with no annotations and no output schema, nothing is said about failure modes, whether the call is idempotent, or what a successful response looks like.

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%, so the schema already explains bucket, data, org, and precision. The description only adds a light gloss on timestamp precision and restates the default org, which is already in the schema.

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?

States a specific verb and resource ('Stream newline-delimited line protocol records into a bucket'), which is unmistakably distinct from sibling tools query-data and create-bucket. It does not explicitly name those siblings, so it lands at 4 rather than 5.

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?

'Use this after composing measurements so the LLM can insert real telemetry' hints at sequencing, and the schema notes the create-bucket prerequisite. There is no explicit when-not guidance or named alternative (e.g., vs. batch import or query-data) in the description itself.

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.4.0
    • Changedcreate-bucket5 fields changed
      • removedInput schema / additionalProperties
        Removed value: -false
      • changedInput schema / properties / retentionPeriodSeconds / description
        Previous value: -"Optional retention duration expressed in seconds. Omit for infinite retention."New value: +"Optional retention duration expressed in whole seconds. Omit (or pass 0) for infinite retention."
      • addedInput schema / properties / retentionPeriodSeconds / maximum
        Added value: +9007199254740991
      • addedInput schema / properties / retentionPeriodSeconds / minimum
        Added value: +0
      • changedInput schema / properties / retentionPeriodSeconds / type
        Previous value: -"number"New value: +"integer"
    • Changedcreate-org1 field changed
      • removedInput schema / additionalProperties
        Removed value: -false
    • Changedquery-data3 fields changed
      • removedInput schema / additionalProperties
        Removed value: -false
      • changedInput schema / properties / org / description
        Previous value: -"Organization whose buckets the query should target (exact name, not ID)."New value: +"Organization whose buckets the query should target (exact name, not ID). Defaults to \"my-organization\" if omitted."
      • changedInput schema / required
        Previous value: -[
-  "org",
-  "query"
-]New value: +[
+  "query"
+]
    • Changedwrite-data3 fields changed
      • removedInput schema / additionalProperties
        Removed value: -false
      • changedInput schema / properties / org / description
        Previous value: -"Human-readable organization name that owns the destination bucket (the same value returned by the orgs resource)."New value: +"Human-readable organization name that owns the destination bucket (the same value returned by the orgs resource). Defaults to \"my-organization\" if omitted."
      • changedInput schema / required
        Previous value: -[
-  "org",
-  "bucket",
-  "data"
-]New value: +[
+  "bucket",
+  "data"
+]
  2. 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."
  3. 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 maps to a distinct resource and action: query-data reads, write-data ingests, create-bucket provisions storage, and create-org provisions a top-level container. There is no plausible way to confuse these operations with one another.

Naming Consistency5/5

All four names follow the same lowercase hyphenated verb_noun convention (query-data, write-data, create-bucket, create-org). The pattern is fully predictable.

Tool Count4/5

Four tools is at the thin end of the acceptable range but each one earns its place in the core write/query workflow. A slightly larger surface (listing/cleanup) would round out the set.

Completeness3/5

The core read/write path plus resource creation is covered, but there are no list or delete operations for buckets or orgs, leaving lifecycle gaps. The create-org description mentions tokens, yet no token tooling exists, creating a dead end.

Maintenance

ActivityNo data
ResponsivenessSyncing

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