Skip to main content
Glama
Sign In
mcp-loki

mcp-loki

by mgcrea
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

Loki: Query Metric

loki_query_metric
Read-only

Evaluate LogQL metric queries at an instant to answer how-many or which-series questions with aggregated counts, rates, or totals over a time window.

Instructions

Evaluate a LogQL metric query at one instant: a count, rate or total over a window written into the query, e.g. errors per namespace over the last hour sum by (namespace) (count_over_time({namespace=~".+"} |= "error" [1h])), or the top 10 topk(10, ...). The right tool for 'how many / which ones' questions — far cheaper than reading lines with loki_query_logs. Labels shared by every series come once as common_labels. Series come back largest value first: LogQL's topk() picks the top N but does not order them.

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"
  }
}

Input Schema

NameRequiredDescriptionDefault
sortNovalue: largest first, applied before `limit` cuts, so a cut keeps the biggest. labels: Loki's own order.value
timeNoEvaluation time: now, now-1h, -30m, an RFC3339 timestamp (2026-01-31T12:00:00Z, nanosecond fractions kept) or unix seconds/nanoseconds. Defaults to now.
limitNoMaximum series to return (1-2000). Defaults to 100. Use topk() in the query to keep the largest instead of raising this.
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.
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

A3.9/5.0
Behavior3/5

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

Annotations already declare readOnlyHint and openWorldHint, so safety is covered. The description adds genuinely useful behavior: shared labels returned once as `common_labels`, series sorted largest-first, and the caveat that topk() selects but does not order. It says nothing about empty results, error behavior, or rate limits, so the extra context is real but narrow.

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 what the tool does, followed by a worked example and a sibling comparison; every element carries information. The final sentence about topk() ordering is dense and slightly tangential to selection, which keeps it from being maximally clean.

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?

With no output schema, the description does the right work by sketching the return shape (per-series values plus `common_labels`) and ordering. It leaves out what an empty or failing query looks like, which would matter for an open-world remote query tool, but nothing essential to issuing a correct call is missing.

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

Parameters3/5

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

Schema description coverage is 100%, so the schema already documents `sort`, `time`, `limit`, `precision`, and `query` thoroughly; baseline is 3. The description adds only one thing beyond the schema: that the time window is written into the query rather than passed as a parameter, plus the topk-vs-limit hint that the schema already echoes.

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?

States a specific verb and resource ('Evaluate a LogQL metric query at one instant') and contrasts with a named sibling ('far cheaper than reading lines with loki_query_logs'). The 'at one instant' phrasing also implicitly distinguishes it from loki_query_metric_range, so an agent can pick between them without opening schemas.

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?

Gives an explicit use case ('how many / which ones' questions) and an explicit alternative with a cost rationale. It does not explicitly say when to prefer loki_query_metric_range over this tool, which is the closest sibling, so the routing is clear but not complete.

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

Deploy Server

Other Tools