A Model Context Protocol (MCP) server for InfluxDB that enables Claude and other AI assistants to work with time-series data
The InfluxDB MCP server has 4 tools with documented descriptions and declared input schemas. However, there are significant gaps in schema completeness, parameter validation, error handling guidance, and composition patterns. All tools have basic descriptions (100-150 chars), which is adequate but not optimized for LLM reasoning. Input schemas are present but lack comprehensive validation (no min/max for numeric fields, no format constraints for strings). Error messages are generic and do not guide recovery. Tool naming follows verb-noun convention (write-data, query-data, create-bucket, create-org), which is good. The core issue is that parameter descriptions are incomplete, several fields lack explanation of valid ranges, formats, or dependencies. For example, 'retentionPeriodSeconds' has no guidance on minimum/maximum values or behavior when omitted. The 'data' parameter in write-data says 'newline-delimited line protocol' but does not explain InfluxDB line protocol syntax or constraints. Output schemas are not documented anywhere in the code, callers must reverse-engineer what fields to expect. Error handling returns plain text error messages without recovery hints (e.g., 'Failed to create bucket' offers no guidance on what to try next). Composition is reasonable (each tool does one thing), but tools do not return IDs needed for chaining, create-org returns 'org.id', but subsequent tools reference the org by name, not ID, which is actually user-friendly but limits programmatic chaining. Overall, this is a functional but not production-grade tool suite.
Provision a new bucket under an organization so that subsequent write-data calls have a destination.
Create a brand-new organization to isolate users or projects before generating buckets and tokens.
Execute a Flux query inside an organization to inspect measurement schemas, run aggregations, or validate recently written data.
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.
Output schemas are undocumented. Callers cannot see what fields create-org, create-bucket, or query-data return. LLMs must guess what to extract from responses, inviting parsing errors.
Parameter 'retentionPeriodSeconds' in create-bucket lacks constraints. No min/max guidance, no documentation of what happens if omitted (infinite retention is mentioned in description but not as a default). LLMs will pass arbitrary large values or negative numbers.
Error messages do not guide recovery. Example: 'Failed to write data: 400 <response>' tells the LLM nothing about what went wrong or what to try next. Should include specific guidance like 'Check if bucket exists, or verify line protocol syntax.'
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 65 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 48 | - | v1 |
Parameter descriptions are incomplete. 'data' in write-data says 'newline-delimited line protocol' but does not explain what line protocol is, what fields are required (tags, fields, timestamps), or what formats are valid. LLMs unfamiliar with InfluxDB will struggle.
No pagination support documented. query-data returns raw CSV text with no indication of result size, pagination tokens, or limits. Large result sets could exhaust the context window.
No dry-run or confirmation pattern for destructive operations. create-bucket and create-org modify state with no way to preview or confirm before execution. An LLM in a planning loop could accidentally create dozens of test organizations.
query-data has no guidance on Flux query syntax. The description says 'Execute a Flux query' but does not link to documentation, explain basic syntax, or provide examples. LLMs will hallucinate invalid queries.