Free Influxdb

InfluxDB 2.7.4 Flux + InfluxQL Grafana ready MIT

Sixty seconds

Get a token from freebase.cloud — create a session with the InfluxDB engine, then Settings → MCP → New Token.

export FREEBASE_MCP_URL="https://freebase.cloud/api/mcp/YOUR_TOKEN"

Write three points of line protocol through the MCP store tool:

bed_climate,bed=A,zone=propagation air_temp=22.4,rh=71.2,vpd=0.78 1755511200000000000
bed_climate,bed=B,zone=veg        air_temp=25.1,rh=58.0,vpd=1.32 1755511200000000000
nutrient,bed=B,line=main          ec=1.84,ph=5.91,water_temp=19.7 1755511200000000000

Read them back with Flux:

from(bucket: "greenhouse")
  |> range(start: -1h)
  |> filter(fn: (r) => r._measurement == "bed_climate" and r._field == "vpd")
  |> aggregateWindow(every: 5m, fn: mean, createEmpty: false)
  |> yield(name: "vpd_5m")

That is the entire loop. Everything below is detail about doing it well.

What this repository contains

A working ingestion-and-query setup for a free InfluxDB 2.7 instance reached over MCP, using a hydroponic greenhouse as the worked example: air temperature, humidity, vapour pressure deficit, nutrient EC and pH, plus discrete dosing events. Four beds, three zones, readings every thirty seconds. It is a small dataset with a realistic shape — high-frequency numeric series, a handful of tags, and one measurement that is events rather than samples.

examples/
├── simulate_greenhouse.py   generates and writes ~2 hours of plausible sensor data
├── run_flux.sh              executes a named query from queries.flux
├── queries.flux             13 Flux queries, from trivial to windowed joins
├── legacy.influxql          the same questions in InfluxQL, where InfluxQL can express them
└── README.md

Line protocol, precisely

One line is one point. The grammar is unforgiving and the error messages are terse, so it is worth knowing exactly:

measurement,tag=value,tag=value field=value,field=value timestamp
            └── comma-separated,   └── comma-separated,  └── integer
                no spaces              no spaces             nanoseconds

• Measurement and tag set are separated by a comma; tag set and field set by a single space; field set and timestamp by a single space. Extra whitespace is a parse error, not a warning.
• Tag values are always strings and are never quoted. bed=A, not bed="A".
• Field values are typed: 22.4 is a float, 22i is an integer, "open" is a string (quoted), t / true is a boolean. A field that arrives as a float on Monday and an integer on Tuesday will be rejected on Tuesday — the type is fixed per field per measurement.
• Timestamps default to nanoseconds. Sending seconds without saying so puts your data in 1970. date +%s%N on Linux gives you the right thing; on macOS it does not, and that has cost people an afternoon.
• Escape commas, spaces and equals signs in measurement, tag keys and tag values with a backslash. Escape double quotes and backslashes inside string field values.

Batch writes. One HTTP round trip carrying five thousand lines is enormously cheaper than five thousand round trips carrying one, and it is the single biggest lever on ingestion throughput.

Tags versus fields — the decision that determines whether this scales

This is the one thing to get right before you write a single point.

Tags are indexed. Fields are not. Anything you filter or group by must be a tag. Anything you do arithmetic on must be a field. That much is in every tutorial.

What the tutorials underplay: every distinct combination of measurement plus tag values creates a separate series, and series count is the resource that actually constrains a time-series database. Four beds × three zones × six sensors is 72 series — nothing. Add reading_id as a tag and you have a new series per point, the index grows without bound, and queries slow down until they stop. This failure has a name in the InfluxDB community — runaway series cardinality — and recovering from it usually means rewriting the schema and re-ingesting.

The rule: a tag value must come from a small, closed set you could write on a whiteboard.

Good tag	Bad tag
bed=A (four values)	reading_id=8f3a... (unbounded)
zone=veg (three values)	timestamp_copy=... (unbounded)
sensor_model=sht41 (a few)	air_temp=22.4 (continuous — this is a field)
firmware=2.3.1 (grows slowly)	raw_payload=... (unbounded, and pointless)

If you genuinely need to keep a high-cardinality identifier, put it in a field. You lose the ability to group by it, which is exactly the operation that would have been expensive anyway.

Flux, read as a pipeline

Flux is functional and left-to-right. Every stage takes a stream of tables and returns a stream of tables, which is why the ordering matters more than it does in SQL.

from(bucket: "greenhouse")                                    // pick the bucket
  |> range(start: -6h)                                        // ALWAYS second — see below
  |> filter(fn: (r) => r._measurement == "nutrient")          // narrow by measurement
  |> filter(fn: (r) => r._field == "ec")                      // then by field
  |> filter(fn: (r) => r.bed == "B")                          // then by tag
  |> aggregateWindow(every: 15m, fn: mean, createEmpty: false)
  |> derivative(unit: 1h, nonNegative: false)                 // EC drift per hour
  |> yield(name: "ec_drift")

Four practical notes:

1. range() is mandatory and belongs immediately after from(). Without it the query is rejected. Putting a filter before it means you have already read more data than you needed.
2. Push filters as early as possible. filter() before aggregateWindow(), always. Flux does some pushdown into storage, but only for the prefix of the pipeline it recognises — one out-of-order stage and everything after it runs in memory.
3. createEmpty: false stops aggregateWindow from emitting null rows for windows with no data. Leave it true and Grafana draws lines through gaps that never existed.
4. yield() names a result. With multiple yield() calls you get multiple named result sets out of one query — genuinely useful when an assistant wants a metric and its baseline together.

queries.flux works through joins across measurements (join() on time and tag), pivoting to wide format (pivot() — the thing that makes Flux output look like a table), moving averages, and histogramQuantile() for percentiles. All thirteen run unchanged against the hosted 2.7 endpoint.

InfluxQL, and when to prefer it

InfluxQL is the v1 SQL-alike, and it is supported here alongside Flux:

SELECT mean("air_temp") FROM "bed_climate"
WHERE "zone" = 'veg' AND time > now() - 6h
GROUP BY time(15m), "bed" fill(none)

Reach for it when: you are migrating a v1 workload, you have existing dashboards written in it, or the question is a plain grouped aggregate and Flux's ceremony is not buying you anything.

Reach for Flux when: you need to join two measurements, apply a custom function, do conditional logic per row, or write a task. InfluxQL cannot join and cannot express arbitrary transformations — that limitation is the reason Flux exists.

Note the quoting convention, which catches everyone: identifiers in double quotes, string literals in single quotes. Swap them and you get a confusing error about an unknown field.

The MCP tools

Name the connection sensors and the four tools are as follows — the same four whatever engine you picked:

Tool	Use
sensors_query	Flux or InfluxQL. The tool passes the statement through; both dialects work.
sensors_store	Line protocol writes. Send many lines in one call, newline-separated.
sensors_list_tables	Measurements in the bucket. The equivalent of SHOW MEASUREMENTS.
sensors_annotate_table	Describe a measurement so the model stops guessing your field names.

Annotation matters more here than on a relational engine, because a model shown a measurement called nutrient has no way to know that ec is millisiemens per centimetre, that ph below 5.5 means the dosing pump has overshot, or that readings arrive every thirty seconds. Tell it once:

nutrient — reservoir chemistry, sampled every 30s. Fields: ec (mS/cm, healthy range 1.2–2.4), ph (target 5.8–6.2), water_temp (°C). Tags: bed (A–D), line (main | drip). A ph value outside 5.0–7.0 is a sensor fault, not a real reading — filter those out before averaging.

That last sentence turns a wrong average into a right one, permanently, for every conversation.

Grafana and downsampling

Grafana takes this as an InfluxDB 2.x data source — URL, token, org and bucket from your freebase.cloud dashboard — and both the Flux and InfluxQL query editors work against it.

For anything you keep long-term, downsample. A Flux task that rolls raw thirty-second readings into hourly summaries in a second bucket keeps dashboards fast and your retention sane:

option task = {name: "greenhouse_hourly", every: 1h}

from(bucket: "greenhouse")
  |> range(start: -1h)
  |> filter(fn: (r) => r._measurement == "bed_climate")
  |> aggregateWindow(every: 1h, fn: mean, createEmpty: false)
  |> set(key: "_measurement", value: "bed_climate_hourly")
  |> to(bucket: "greenhouse_rollup")

Set a short retention on the raw bucket and a long one on the rollup. That pattern is the whole of time-series data management, and it is worth setting up on day one rather than day ninety.

When InfluxDB is not what you want

• Relational questions. "Which customers on the enterprise plan had an outage last month" is a join across entities. InfluxDB has one join and it is awkward. Use Postgres.
• Time-series that also need joins and SQL. TimescaleDB is Postgres with hypertables — you keep time_bucket() and continuous aggregates and real SQL. If your time-series data lives next to business tables, that is usually the better fit, and it is also available on freebase.cloud.
• Wide analytical scans over billions of rows. ClickHouse will beat this comfortably.
• Anything requiring updates. Time-series data is append-only by design. Correcting a point means overwriting it by identical timestamp and tag set, and there is no UPDATE ... WHERE.
• Event logs you want to full-text search. Store the metrics here, the text in Elasticsearch.

Where it wins: high-frequency numeric measurements, tagged by a small set of dimensions, queried over time windows. That is IoT telemetry, infrastructure metrics, application latency and tick data — and for those it is very hard to beat.

Client setup

The endpoint is a single streamable-HTTP URL, so most clients need two lines.

Claude Code

claude mcp add --transport http sensors https://freebase.cloud/api/mcp/YOUR_TOKEN

n8n — this is the one that fits IoT work best. Add an MCP Client Tool node (n8n 1.104.0 or newer), set Server Transport to HTTP Streamable, paste the endpoint, Authentication None. The published docs page still shows only an "SSE Endpoint" field; the node in a current build has the transport dropdown.

LangChain

from langchain_mcp_adapters.client import MultiServerMCPClient

client = MultiServerMCPClient({
    "sensors": {"transport": "http", "url": "https://freebase.cloud/api/mcp/YOUR_TOKEN"}
})
tools = await client.get_tools()

LlamaIndex

from llama_index.tools.mcp import BasicMCPClient, McpToolSpec

spec = McpToolSpec(client=BasicMCPClient("https://freebase.cloud/api/mcp/YOUR_TOKEN"))
tools = await spec.to_tool_list_async()

Claude Desktop takes remote servers only through its interface — open Settings, find Connectors, choose Add custom connector and paste the URL. There is no JSON field for an HTTP MCP server in the desktop config file, and a Free account can hold a single custom connector. There is a step-by-step Claude Desktop walkthrough covering the same screens.

Free tier

InfluxDB 2.7.4 with line protocol ingestion, Flux, InfluxQL, buckets with configurable retention, scheduled tasks, and the v1 /query and /write compatibility endpoints that Telegraf and older agents expect. Grafana connects as a normal data source.

Scoped for development, prototyping and small production workloads. A greenhouse, a home lab, a handful of services, a demo dashboard — comfortable. A fleet of ten thousand devices at one-second resolution — not what this tier is for. Current retention and quota figures live in the dashboard.

InfluxDB Cloud is the answer for production scale, dedicated clusters and a support relationship. This is the answer for having somewhere to put sensor data this afternoon — see the InfluxDB instance page for what the tier includes.

Reference

• InfluxDB 2.x documentation
• Line protocol reference
• Flux standard library
• Model Context Protocol — spec revision 2026-07-28
• Free InfluxDB cloud instance

---

freebase.cloud is an independent service and is not affiliated with InfluxData, Grafana Labs, Anthropic or n8n.