Skip to main content
Glama
mcp-loki

mcp-loki

by mgcrea

Loki: Query Metric Range

loki_query_metric_range
Read-only

Evaluate LogQL metric queries over a time range to spot log-volume or error-rate spikes, when they started, and which service they came from, with per-series stats and optional step values.

Instructions

Evaluate a LogQL metric query over a time range, for how log volume or error rates changed: a spike, when it started, which service it came from. Each series comes back with stats (min, max, avg, last) and, with view=values, one value per step on a shared grid given by start and step (null where there was nothing). The step is picked for about 60 points unless given; the range in the query ([5m]) is independent of it, and usually should match it. Aggregate with sum by — one series per stream is rarely what you want and quickly hits max_query_series.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "query": "<query>"
    },
    "name": "loki_query_metric_range"
  }
}

Input Schema

NameRequiredDescriptionDefault
endNoRange end: now, now-1h, -30m, an RFC3339 timestamp (2026-01-31T12:00:00Z, nanosecond fractions kept) or unix seconds/nanoseconds. Defaults to now.
sortNoOrder of series, applied before `limit` cuts: labels keeps Loki's order; max/avg/last rank highest first, so a cut keeps the biggest.labels
stepNoResolution, as a duration (30s, 5m, 1h) or seconds. Defaults to a round step giving about 60 points.
viewNovalues: stats plus the value at every step. stats: min/max/avg/last only, about a tenth of the size — use it to survey many series before plotting a few.values
limitNoMaximum series to return (1-500). Defaults to 20.
queryYesA LogQL metric query: a range aggregation over a log query, usually aggregated by a label, e.g. `sum by (namespace) (count_over_time({namespace=~".+"} |= "error" [5m]))` or `sum by (status) (rate({app="nginx"} | json [1m]))`. Unwrapped values: `avg_over_time({app="api"} | json | unwrap duration_ms [5m])`. Always aggregate (sum by) unless you want one series per stream.
startNoRange start: now, now-1h, -30m, an RFC3339 timestamp (2026-01-31T12:00:00Z, nanosecond fractions kept) or unix seconds/nanoseconds. Defaults to now-1h.
precisionNoSignificant digits to round fractional values to (whole numbers are never rounded). Defaults to 4; 0 returns the exact value.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.2.0

TDQS

A4/5.0
Behavior4/5

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

Annotations already cover read-only and open-world, so the bar is lower, but the description still adds substance: per-series stats (min/max/avg/last), per-step values on a shared grid with nulls for gaps, and the max_query_series failure mode. It does not discuss permissions, backend load, or what the response envelope looks like, but the safety profile is already declared.

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?

Front-loaded with purpose and then the return shape, with no filler sentences. It is dense — the step/range and sum-by caveats are packed into single clauses — but each sentence carries information.

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

Completeness4/5

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

No output schema exists, and the description compensates by describing the returned series, stats fields, and the null-per-step behavior. With 8 params all documented in the schema, the main remaining gap is the missing contrast with the instant-query sibling.

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 100%, so baseline is 3, but the description adds semantics the schema cannot: the auto step targets ~60 points, and the range selector inside the query (`[5m]`) is independent of `step` and 'usually should match it' — a genuinely non-obvious coupling. sort/limit interplay is repeated from the schema, so it's not purely additive.

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

Purpose4/5

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

The description opens with a specific verb and resource: 'Evaluate a LogQL metric query over a time range,' and adds the intent (log volume/error-rate trends, spike onset, service attribution). That distinguishes it from loki_query_logs and loki_get_volume on intent. It never mentions the sibling loki_query_metric, so the range-vs-instant boundary is left implicit.

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

Usage Guidelines4/5

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

It gives real selection guidance: use view=stats 'to survey many series before plotting a few,' and always aggregate with 'sum by' because one series per stream 'quickly hits max_query_series.' What's missing is an explicit when-not or a named alternative (loki_query_metric for a single instant, loki_query_logs for raw lines).

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