Skip to main content
Glama
Sign In
mcp-loki

mcp-loki

by mgcrea
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

Loki: List Rules

loki_list_rules
Read-only

List Loki ruler alerting and recording rules with health, last error, and firing state (firing first). Filter by type, state, or name, and optionally include each rule's LogQL expression.

Instructions

List the Loki ruler's alerting and recording rules (LogQL rules evaluated by Loki itself, not Prometheus or Grafana-managed alerts), with health, last error and, for alerts, whether they are firing — firing first. Answers an empty list when no rule groups exist for this tenant, and 404 when the ruler is not deployed or not routed.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "loki_list_rules"
  }
}

Input Schema

NameRequiredDescriptionDefault
typeNoOnly alerting rules (alert) or only recording rules (record).
stateNoOnly alerting rules in this state.
searchNoCase-insensitive substring to filter by, e.g. `api`.
include_queryNoInclude each rule's LogQL expression. Off by default: it is most of the size.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.2.0

TDQS

A4.4/5.0
Behavior5/5

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

Beyond the readOnlyHint/openWorldHint annotations, the description discloses result ordering (firing first), the payload fields surfaced (health, last error, firing state), and two non-obvious response behaviors: an empty list when no rule groups exist for the tenant versus a 404 when the ruler is not deployed or routed. That distinction is exactly the kind of context annotations cannot carry.

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?

The core purpose is front-loaded in the first clause, and the parenthetical disambiguation and error semantics follow logically; no sentence is filler. The single long sentence with multiple em-dash and comma-separated clauses is dense and slightly harder to scan than it needs to be.

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 no output schema, the description carries the return-value burden itself and does so by naming the fields returned and the sort order. Combined with the empty-list versus 404 semantics, an agent has everything needed to call this and interpret both success and failure.

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%, including enum values for type and state and a rationale for include_query being off by default, so the schema already does the parameter work. The description adds only an indirect hint about filtering via the 'for alerts, whether they are firing' phrasing and does not explain how type/state/search interact.

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?

Specific verb (List) plus specific resource (Loki ruler's alerting and recording rules), with an explicit scoping clause that this is LogQL rules evaluated by Loki itself, not Prometheus or Grafana-managed alerts. That parenthetical alone differentiates it from adjacent observability tools an agent might otherwise reach for.

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?

The description gives clear qualifying context by excluding the Prometheus/Grafana-managed alerting surface and noting the 404 case when the ruler is not deployed or not routed, which tells the agent what a failure means. It does not name a sibling tool as the alternative for the Prometheus/Grafana case, so the routing signal is implied rather than stated.

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