Skip to main content
Glama
influxdata

InfluxDB MCP Server

Official
by influxdata

query_influxql

Run a bounded, read-only InfluxQL query against an InfluxDB 3 database to retrieve structured rows, warnings, and query metadata.

Instructions

Run one bounded, read-only InfluxQL query against an InfluxDB 3 database. Accepts database as an alias for db and query as an alias for q; differing pairs are rejected. Defaults to JSON output and returns structured rows, warnings, and query metadata. Core and Enterprise also return jsonl or csv; Cloud Dedicated, Cloud Serverless, and Clustered return only JSON. Your answer must report metadata.completeness, the cap when capped, warnings, and row_count; see READING QUERY RESULTS in get_help. Rejects SELECT INTO and destructive statements. Prefer query_sql for SQL prompts; use InfluxQL regex field selection only when the user explicitly asks for InfluxQL or regex field matching. For regex field selection, write SELECT /pattern/ FROM m; a type suffix such as /pattern/::field fails to parse.

Input Schema

NameRequiredDescriptionDefault
qNoRead-only InfluxQL query to run. Provide q or query; if both are present, they must agree.
dbNoDatabase name to query. Provide db or database; if both are present, they must agree.
queryNoAlias for q; provide one or equal values.
formatNoOutput format for query results. Core and Enterprise return json, jsonl, or csv; Cloud Dedicated, Cloud Serverless, and Clustered return json. Other formats are refused with unsupported_query_format.json
paramsNoOptional query parameters to pass through
maxRowsNoMaximum rows to return. Default 1000; hard max 5000.
databaseNoAlias for db; provide one or equal values.
timeoutMsNoOptional query timeout in milliseconds

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed9 schema fields changedv2.0.0
    • addedInput schema / properties / database
      Added value: +{
      +  "description": "Alias for db; provide one or equal values.",
      +  "type": "string"
      +}
    • changedInput schema / properties / db / description
      Previous value: -"Database name to query"New value: +"Database name to query. Provide db or database; if both are present, they must agree."
    • changedInput schema / properties / format / description
      Previous value: -"Output format for query results"New value: +"Output format for query results. Core and Enterprise return json, jsonl, or csv; Cloud Dedicated, Cloud Serverless, and Clustered return json. Other formats are refused with unsupported_query_format."
    • changedInput schema / properties / maxRows / type
      Previous value: -"number"New value: +"integer"
    • addedInput schema / properties / params / anyOf
      Added value: +[
      +  {
      +    "type": "object"
      +  },
      +  {
      +    "type": "array"
      +  }
      +]
    • changedInput schema / properties / q / description
      Previous value: -"Read-only InfluxQL query to run"New value: +"Read-only InfluxQL query to run. Provide q or query; if both are present, they must agree."
    • addedInput schema / properties / query
      Added value: +{
      +  "description": "Alias for q; provide one or equal values.",
      +  "type": "string"
      +}
    • changedInput schema / properties / timeoutMs / type
      Previous value: -"number"New value: +"integer"
    • changedInput schema / required
      Previous value: -[
      -  "db",
      -  "q"
      -]New value: +[]
  2. First observedv1.4.1-test.1

TDQS

A4.8/5.0
Behavior5/5

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

With no annotations, the description carries the full behavioral burden and does so well: it states read-only and bounded behavior, rejects SELECT INTO and destructive statements, explains alias conflict rejection, describes deployment-dependent output formats, and says results include rows, warnings, and metadata. It also tells the agent what must be reported from the results.

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?

The purpose is front-loaded and the sentences are information-dense rather than padded. It is somewhat packed with multiple operational details, but each item is relevant to correct invocation and result handling.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a complex query tool with no annotations and no output schema, the description covers the important gaps: what it runs, what it refuses, how aliases behave, deployment-dependent formats, what the response contains, and how to interpret completeness and warnings. It also points to get_help for deeper reading guidance.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is already 100%, so the baseline is 3. The description adds meaningful semantics beyond the schema by explaining alias equivalence and rejection of conflicting db/database or q/query pairs, plus output-format availability by deployment and the JSON default.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description gives a specific verb and resource: 'Run one bounded, read-only InfluxQL query against an InfluxDB 3 database.' It also explicitly distinguishes this tool from query_sql and frames the scope around InfluxQL rather than generic query execution.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It explicitly says to prefer query_sql for SQL prompts and to use InfluxQL regex field selection only when the user explicitly asks for InfluxQL or regex field matching. That is clear routing guidance with an exclusion condition.

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