InfluxDB Cloud

@InfluxDB Cloud show me the structure of this Flux query: from(bucket:"metrics") |> range(start: -1h) |> filter(fn: (r) => r._measurement == "cpu")

The Flux query AST shows a valid three-stage pipeline: a `from()` call targeting the "metrics" bucket, followed by a `range()` filter for the last hour, and a `filter()` function checking for CPU measurements. The AST confirms proper syntax with no parsing errors. Each pipe operator correctly chains the transformations, and the anonymous function in the filter uses valid record notation (r._measurement).

This example demonstrates query validation before execution. The AST tool catches syntax errors early, which is critical when building complex time-series queries programmatically. Requires a valid API key with read access to the organization's buckets. Does not execute the query or return data—only validates structure.

@InfluxDB Cloud add a new cell to dashboard d09abad1c0ffee showing the last 24 hours of memory usage from the "system" bucket

Cell added successfully to dashboard d09abad1c0ffee. The new visualization displays memory usage metrics from the "system" bucket with a 24-hour time range. The cell was positioned in the next available grid slot and uses a default line graph view. You can adjust the cell's query, visualization type, and position through the InfluxDB UI or by calling the update cell tool with the returned cell ID.

This write operation modifies dashboard state immediately. The example assumes the dashboard ID exists and your API key has write permissions to dashboards. The tool does not validate whether the bucket or measurement exists—if the query references missing data, the cell will render empty. Always verify dashboard IDs before adding cells to avoid orphaned visualizations.

@InfluxDB Cloud list all available API routes for this instance and summarize which endpoints handle user management versus data queries

The instance exposes 47 API routes. User management endpoints include `/api/v2/users` (list, create), `/api/v2/users/{id}` (get, update, delete), and `/api/v2/signin` / `/api/v2/signout` for session handling. Data query routes center on `/api/v2/query` (Flux execution) and `/api/v2/write` (line protocol ingestion). Additional routes cover buckets, dashboards, tasks, and DBRP mappings. Operator-level routes like user deletion require elevated token permissions.

This discovery example pairs the MCP's route-listing tool with AI reasoning to categorize endpoints by function. Useful when onboarding to a new InfluxDB instance or auditing available capabilities. The route list reflects your token's permission scope—restricted tokens may not see all endpoints. Does not execute any operations, only returns metadata.

When InfluxDB Cloud MCP fits real-time device monitoring

A 6-person operations team tracking temperature sensors across 40 retail locations needs to add new dashboard cells during incident response. This MCP is the right call if your team already runs InfluxDB Cloud for time-series storage and wants AI to manipulate dashboards without leaving Switchy. The Add Dashboard Cell and Generate Flux Query AST tools let you prototype visualizations in chat, validate the query syntax, and push cells live. The threshold: if you're not already on InfluxDB Cloud, the setup cost (API keys, learning Flux) outweighs the benefit for casual dashboard edits. If your ops team lives in InfluxDB daily and needs to iterate dashboards fast during outages, this MCP saves the context-switch to the web UI.

Why this MCP works for InfluxDB user lifecycle

A 3-person platform team managing a multi-tenant InfluxDB Cloud instance needs to onboard and offboard users as customers churn. The Delete User and Sign In tools let you script user lifecycle tasks from Switchy without writing custom API wrappers. This is a win if you're already automating InfluxDB admin tasks and want to centralize them in your AI workspace. The trade-off: the MCP requires an operator token, so you're granting Switchy elevated permissions. If your security posture allows scoped API keys and you run these tasks weekly, the MCP beats manual console clicks. If you onboard users once a quarter, the overhead of managing the token in Switchy isn't worth it—just use the web UI.

When to use this MCP for database-retention mapping

A 2-person backend team migrating a legacy InfluxDB 1.x app to Cloud needs to update DBRP mappings as they test retention policies. The Get DBRP Mapping and Update DBRP tools let you query and tweak mappings in chat while debugging query failures. This MCP is the right fit if you're mid-migration, running dozens of mapping experiments, and tired of toggling between docs and the API console. The boundary: if you're only setting up DBRP once at cutover, the MCP is overkill—just use the Cloud UI or a one-off curl script. If you're iterating on retention policies across 10+ databases and need to validate changes fast, this MCP keeps the workflow in Switchy where your migration notes already live.