influxdata / influxdata/influxdb3_mcp_server
Normalize query options across Cloud Dedicated, InfluxDB Clustered, and Cloud Serverless
- Dominant language
- TypeScript
- Stars
- 38
- Forks
- 14
- Avg merge
- 5d 9h
- Merged PRs (30d)
- 7
Description
## Problem
The MCP query surface advertises one `params` and `timeoutMs` contract, but `QueryService` currently exposes transport-specific behavior:
- Cloud Dedicated and Cloud Serverless use the Flight client, which forwards named scalar `params` but does not provide a per-query timeout option.
- InfluxDB Clustered uses an HTTP `/query` route, which currently receives both `params` and an Axios timeout.
This leaks implementation details through the public MCP contract. It also risks conflating **InfluxDB Clustered** (a distinct product) with an InfluxDB 3 Enterprise cluster.
## Expected behavior
Give `query_sql` and `query_influxql` a transport-independent query-options contract across Cloud Dedicated, InfluxDB Clustered, and Cloud Serverless.
The implementation may use different transports internally, but callers should see consistent behavior for `params` and `timeoutMs`. If an option truly cannot be supported, handle it consistently and explicitly at the MCP boundary rather than silently dropping it or varying by route.
## Acceptance criteria
- Routing/capability tests cover Cloud Dedicated, InfluxDB Clustered, and Cloud Serverless separately.
- The three products have consistent observable handling for `params` and `timeoutMs` on each supported query language.
- SQL and InfluxQL select an appropriate backend transport; do not treat the v1-compatible `/query` endpoint as a generic SQL route.
- Errors for genuinely unsupported options are stable, documented, and returned before dispatch.
- Product terminology consistently distinguishes InfluxDB Clustered from an InfluxDB 3 Enterprise cluster.
## Related
Follow-up to #84.
Contributor guide
No contributing guide indexed for this repository
Research direction
Start by tracing QueryService and the MCP boundary for query_sql and query_influxql, then follow the Cloud Dedicated, InfluxDB Clustered, and Cloud Serverless routing paths. Add separate capability tests for each product and language, verify consistent params and timeoutMs handling before dispatch, and confirm stable unsupported-option errors and terminology.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- typescript
- Domain
- api, backend
- Issue type
- Refactor
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Quiet
- Clarity
- Mostly clear
- Newbie friendliness
- 45/100