Skip to main content
Glama

series

Read-onlyIdempotent

List log streams matching a LogQL selector as complete label sets, so you can see if anything matches and how many streams you would read before running a query.

Instructions

List the log streams matching a selector, as complete label sets.

Use it to see which concrete streams a selector actually covers and what other labels they carry: {app="nginx"} may expand to one series per pod, region or level. That answers "does this selector match anything" and "how many streams am I about to read" without fetching log lines. For the lines themselves, use query_range; for label names and values in isolation, use labels and label_values.

Returns the raw Loki JSON response: {"status","data":[{"label":"value"}]}, one object per stream. A selector matching nothing comes back as an empty list. Read-only: it never writes to or mutates Loki.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
endNoEnd of the time range, RFC3339 or Unix nanoseconds. Defaults to now.
matchYesStream selector in LogQL brace syntax, e.g. {app="nginx"} or {namespace="prod",level=~"error|warn"}. Line filters (|=) are not accepted here.
startNoStart of the time range, RFC3339 (2026-03-25T10:00:00Z) or Unix nanoseconds. Defaults to 6 hours ago.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changedv0.0.3
    • changedInput schema / properties / end / description
      Previous value: -"End of time range (RFC3339 or Unix nanoseconds). Defaults to now"New value: +"End of the time range, RFC3339 or Unix nanoseconds. Defaults to now."
    • changedInput schema / properties / match / description
      Previous value: -"Stream selector (e.g. {app=\"nginx\"})"New value: +"Stream selector in LogQL brace syntax, e.g. {app=\"nginx\"} or {namespace=\"prod\",level=~\"error|warn\"}. Line filters (|=) are not accepted here."
    • changedInput schema / properties / start / description
      Previous value: -"Start of time range (RFC3339 or Unix nanoseconds). Defaults to 6 hours ago"New value: +"Start of the time range, RFC3339 (2026-03-25T10:00:00Z) or Unix nanoseconds. Defaults to 6 hours ago."
  2. First observedv0.1.0

TDQS

A4.7/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the read-only safety is covered. The description adds valuable context beyond annotations: the exact return shape (raw Loki JSON with status/data), the empty-list behavior for no matches, and a concrete example of selector expansion. It also repeats the read-only guarantee, reinforcing but not contradicting the annotations.

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?

The description is compact yet thorough, leading with the core action, then purpose, usage guidance, return format, and safety note. Every sentence adds new information—no redundant fluff. The alternative-tool routing is front-loaded and the response format is clearly specified up front, making it easy to scan.

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 tool with three parameters and no output schema, the description is exceptionally complete. It covers the raw JSON structure, empty-list case, read-only nature, selector expansion, and explicitly routes to sibling tools. Time range defaults are in the schema, and the description complements rather than duplicates, leaving nothing essential missing for an agent to call it 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?

The schema covers all three parameters at 100% with clear descriptions, including the match selector syntax and time range defaults. The description adds significant extra semantic value by explaining the expansion behavior ('{app="nginx"} may expand to one series per pod, region or level'), which directly illuminates how the match parameter behaves in practice, beyond a simple field description.

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 opens with a specific verb and resource ('List the log streams matching a selector') and immediately clarifies it returns complete label sets. It explicitly differentiates from siblings by naming query_range, labels, and label_values as alternatives for different purposes, making the tool's unique role unmistakable.

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?

The description states exactly when to use this tool ('to see which concrete streams a selector actually covers', 'does this selector match anything', 'how many streams am I about to read') and gives explicit exclusions: 'For the lines themselves, use query_range; for label names and values in isolation, use labels and label_values.' This leaves no ambiguity about when to choose this tool over siblings.

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