Skip to main content
Glama
mcp-loki

mcp-loki

by mgcrea

Loki: Query Logs

loki_query_logs
Read-only

Run a LogQL query over a time range to retrieve matching log lines across streams, newest first, with paging and label controls for focused troubleshooting.

Instructions

Run a LogQL log query over a time range and return the matching lines, newest first by default, merged across streams into one time-ordered list. Labels shared by every stream come once as common_labels; each line carries only the labels that tell its stream apart, plus level and structured-metadata fields (parsed ones with parsed_fields). When more is true, call again with next's start, end and skip to page on. To count or rank rather than read (errors per namespace, top talkers), use loki_query_metric instead: it is far cheaper than reading lines. loki_get_stats tells you how much a selector would scan.

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

Input Schema

NameRequiredDescriptionDefault
endNoRange end (exclusive): now, now-1h, -30m, an RFC3339 timestamp (2026-01-31T12:00:00Z, nanosecond fractions kept) or unix seconds/nanoseconds. Defaults to now.
skipNoFrom `next`: how many lines at the page boundary were already returned. Pass `next` back whole; leave this unset otherwise.
limitNoMaximum lines to return (1-5000; Loki's own max_entries_limit_per_query may be lower). Defaults to 100. Page with `next` rather than raising it.
queryYesA LogQL log query: a stream selector, then filters and parsers, e.g. `{namespace="payments", app="api"} |= "error" != "healthcheck" | json | status >= 500`. Put the cheap parts first: label matchers decide how much is read at all, then line filters (|=, !=, |~), and only then parsers (| json, | logfmt). At least one matcher must not match the empty string: `{app=~".+"}` works, `{app=~".*"}` and `{}` are rejected.
startNoRange start: now, now-1h, -30m, an RFC3339 timestamp (2026-01-31T12:00:00Z, nanosecond fractions kept) or unix seconds/nanoseconds. Defaults to 1 hour before end.
directionNobackward: newest lines first, so the limit keeps the most recent. forward: oldest first, to read what happened from the start of the range.backward
hide_labelsNoStream labels to leave out of the answer. Defaults to ["filename"], which on Kubernetes is a 120-character /var/log/pods/... path repeating namespace, pod and container. Pass [] to see every label.
parsed_fieldsNoInclude the labels extracted by | json, | logfmt, | regexp or | pattern on each line, under `fields`. Off by default because they restate the line itself and double its size; turn it on after line_format or keep has reshaped the line, or to read a nested JSON value flattened. Structured metadata (trace_id, detected_level) is always included.
max_line_charsNoCut each line at this many characters (80-100000); a cut line ends with `… [+N chars]`. Defaults to 2000. Some services log single lines of hundreds of KB.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.2.0

TDQS

A4.6/5.0
Behavior4/5

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

Annotations already declare readOnlyHint and openWorldHint, so the safety profile is free; the description still adds real behavior beyond that: default backward ordering, stream merging, label de-duplication into `common_labels`, per-line `level` and `fields`, and the `more`/`next` paging contract. It stops short of error behavior, rate limits, or any auth/permission caveats, which keeps it off a 5.

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 the core action and result shape, then paging, then sibling routing — a sensible order with no filler sentences. It is dense with output-shape detail (common_labels, level, fields, parsed_fields) that slightly overlaps what the schema already says, costing it a point on strict economy.

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?

With 9 parameters, no output schema, and a complex LogQL surface, the description carries the return-value burden itself — it describes the merged list, shared versus per-stream labels, and paging tokens. Combined with 100% schema coverage on inputs, an agent has everything needed to call it and interpret the response correctly.

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 individual parameters are already documented and the baseline is 3. The description still adds cross-parameter meaning the schema cannot: paging is a coordinated reuse of `next`'s start, end and skip, and `parsed_fields` is tied to the `fields` output it enables. That earns one point above baseline without re-documenting fields verbatim.

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+resource ("Run a LogQL log query over a time range") and immediately pins the output shape ("matching lines, newest first by default, merged across streams into one time-ordered list"). It explicitly distinguishes itself from loki_query_metric and loki_get_stats, so an agent can separate the three without opening any schema.

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?

Gives explicit when-to-use-this versus alternatives: read lines here, but "To count or rank rather than read (errors per namespace, top talkers), use loki_query_metric instead: it is far cheaper than reading lines," and points to loki_get_stats for scan estimation. It also explains the paging condition ("When `more` is true, call again with `next`'s start, end and skip"), which is a usage rule rather than a schema fact.

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