mcp-loki

Loki: List Patterns

loki_list_patterns

Read-only

Summarize log streams as line templates with occurrence counts, ordered by frequency, to quickly see service activity or detect new flooding messages without reading raw lines.

Instructions

Summarize what a set of streams is logging as line templates (<_> marks the variable parts) with how often each occurred, most frequent first. The fastest way to see what a service is doing, or which new message started flooding, without reading lines. Patterns are built by the pattern ingester from recent data (typically the last few hours) and need it to be enabled (see loki_auth_status).

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": {
      "selector": "<selector>"
    },
    "name": "loki_list_patterns"
  }
}

Input Schema

Name	Required	Description
`end`	No	Range end: now, now-1h, -30m, an RFC3339 timestamp (2026-01-31T12:00:00Z, nanosecond fractions kept) or unix seconds/nanoseconds. Defaults to now.
`level`	No	Keep only patterns of this detected level, e.g. `error` or `warn`.
`limit`	No	Maximum patterns to return (1-500), most frequent first. Defaults to 30.
`start`	No	Range 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.
`search`	No	Case-insensitive substring to filter by, e.g. `api`.
`selector`	Yes	A stream selector, e.g. `{namespace="payments", app="api"}`. Label matchers only: no line filters or parsers. At least one matcher must not match the empty string: `{app=~".+"}` works, `{app=~".*"}` and `{}` are rejected.
`max_chars`	No	Cut each pattern at this many characters. Defaults to 500.

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.2.0Nov 6, 2026

TDQS

A4.3/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 covered. The description adds real value the annotations cannot: results are computed by an ingester from recent data only (typically the last few hours), so results may be stale or empty for older ranges, and the feature can be disabled. It stops short of describing pagination or what an empty result means.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three sentences, front-loaded with what the tool returns before the persuasive framing, then the operational caveat. No filler, and the `<_>` notation is explained inline rather than deferred.

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 7-parameter read tool with full schema coverage and no output schema, the description covers the result format, ordering, the data-freshness limitation and the enabling prerequisite. An agent has everything needed to call it correctly and to interpret an empty or stale response.

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%, with detailed semantics for selector, time range, limit, level, search and max_chars already documented. The description adds only the `<_>` template convention and the frequency ordering, which the `limit` schema field also states. Baseline 3 is appropriate where the schema does the heavy lifting.

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 — summarize a set of streams' log lines as templates — and describes the output shape (`<_>` variable markers, frequency counts, most-frequent-first ordering). The phrase 'without reading lines' implicitly distinguishes it from loki_query_logs, so an agent can pick it without opening either schema.

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 concrete use cases ('see what a service is doing', 'which new message started flooding') and a clear exclusion implied by 'without reading lines'. It also states a hard prerequisite: the pattern ingester must be enabled, pointing at loki_auth_status for the check. It never names a sibling tool explicitly as the alternative, which keeps it short of a 5.

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

Deploy Server