Skip to main content
Glama
Sign In
mcp-loki

mcp-loki

by mgcrea
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

Loki: Get Stats

loki_get_stats
Read-only

Estimate streams, chunks, log lines, and bytes for a Loki stream selector over a time range without reading logs. Run it before expensive queries to narrow selectors that may be slow or time out.

Instructions

How much data a stream selector covers over a range — streams, chunks, log lines and bytes — from the index, without reading any of it. Call it before an expensive loki_query_logs or a long metric range: a selector covering tens of GB will be slow or time out, and should be narrowed first.

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

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.
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.
selectorYesA 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.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.2.0

TDQS

A4.4/5.0
Behavior4/5

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

Annotations already declare readOnlyHint and openWorldHint, but the description adds non-obvious behavior: the numbers come from the index without scanning log content, so the call is cheap, and the result is a proxy for whether a later query will be slow or time out. It does not mention cardinality limits, grouping, or whether the stats are approximate.

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?

Two sentences: the first defines the metric and its source, the second gives the call-order advice. Nothing is repeated and the most actionable guidance comes after the necessary definition.

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 usefully names the four returned measures, and the annotations cover the safety profile. It stops short of saying how to interpret the numbers (e.g., thresholds other than tens of GB) or whether results are aggregated per stream, but an agent has enough to call it correctly.

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 coverage is 100%, so selector syntax restrictions and start/end formats are already documented in the schema. The description only reinforces that the range applies to a selector's coverage; it adds no examples or semantics beyond the schema, which is the baseline case.

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 (measure how much data a stream selector covers) plus the exact outputs (streams, chunks, log lines, bytes) and the mechanism (index, without reading log data). This clearly separates it from loki_query_logs, loki_get_volume and the metric tools.

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 an explicit call-order rule: run this before an expensive loki_query_logs or a long metric range, and narrow the selector if it covers tens of GB. That names both the alternative tools and the decision criterion, leaving little to infer.

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