Skip to main content
Glama
Sign In
mcp-loki

mcp-loki

by mgcrea
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

Loki: List Label Values

loki_list_label_values
Read-only

List values of a Loki stream label, optionally filtered by a selector, to find exact label spelling for selectors instead of guessing with regex.

Instructions

List the values of one stream label, e.g. every namespace or every app, optionally only among streams matching a selector (the pods of one namespace). Use it to find the exact spelling to put in a selector rather than guessing with a regex.

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": {
      "label": "<label>"
    },
    "name": "loki_list_label_values"
  }
}

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.
labelYesThe label name, e.g. `namespace`, `app`, `service_name`, `pod`.
limitNoMaximum values to return (1-5000). Defaults to 200.
startNoRange start: now, now-1h, -30m, an RFC3339 timestamp (2026-01-31T12:00:00Z, nanosecond fractions kept) or unix seconds/nanoseconds. Defaults to 6 hours before end.
searchNoCase-insensitive substring to filter by, e.g. `api`.
selectorNoA 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

A3.8/5.0
Behavior3/5

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

The readOnly/openWorld annotations already establish this as a safe, external read, so the description's job is to add context. It contributes the selector-scoping behavior and the lookup-for-exact-spelling intent, but says nothing about result truncation, the default 200 limit, or ordering, which matter for a list endpoint capped at 5000.

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, front-loaded with the core action, then the usage rationale. No redundant restatement of the tool name and no filler.

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?

For a read-only single-label lookup with a fully described schema and no output schema, the description covers what the tool returns, why you'd call it, and how the selector narrows scope. Minor gaps around truncation/limit behavior are largely covered by the schema.

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 every parameter is already documented, establishing a baseline of 3. The description's contribution is the conceptual link between label and selector ('the pods of one namespace'), with no format or default details beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

Opens with a specific verb and resource ('List the values of one stream label'), and the namespace/app examples make the label-name vs label-value distinction concrete. It never names loki_list_labels directly, so an agent must infer the sibling split from phrasing alone.

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 a clear use case with rationale: find the exact spelling for a selector 'rather than guessing with a regex,' and notes the optional narrowing by selector. There is no explicit when-not-to-use guidance or pointer to alternative tools such as loki_list_labels or loki_list_series.

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