Skip to main content
Glama
Sign In
mcp-loki

mcp-loki

by mgcrea
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

Loki: Request

loki_request
Read-only

Call any raw Loki read endpoint the named tools don't cover, such as format_query, volume_range, alerts, or config. Ideal for fetching unshaped GET responses when no dedicated tool exists.

Instructions

Escape hatch: GET any Loki read endpoint the other tools do not wrap — /loki/api/v1/index/volume_range, /loki/api/v1/format_query (pretty-prints and validates LogQL without running it), /prometheus/api/v1/alerts, or /config (this Loki's whole running configuration, as YAML). The answer is the raw data (or text), unshaped, cut at max_chars. Read-only: only GET is ever sent. Prefer the named tools, which shape their output.

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": {
      "path": "<path>"
    },
    "name": "loki_request"
  }
}

Input Schema

NameRequiredDescriptionDefault
pathYesAPI path, e.g. "/loki/api/v1/format_query".
paramsNoQuery parameters, e.g. {"query": "{app=\"api\"}"}. Times are best sent as unix nanoseconds or RFC3339. A repeated parameter is an array.
max_charsNoCut the answer at this many characters (100-200000). Defaults to 20000.

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=true and openWorldHint=true, and the description reinforces that only GET is ever sent. It adds useful behavioral context that the answer is raw and unshaped, cut at max_chars, and that format_query only validates LogQL without running it. It does not cover auth, rate limits, or error behavior, so it is strong but not exhaustive.

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 front-loaded with the escape-hatch purpose, then gives examples, response behavior, safety, and sibling-tool preference without wasted wording. The examples are dense but directly useful for selecting and invoking the tool.

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 generic open-ended request tool with no output schema, the description explains the response is raw data or text, unshaped, and truncated at max_chars. That is enough to call it correctly, though it leaves auth, error, and endpoint-discovery edge cases implicit.

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%, so path, params, and max_chars are already documented in the schema. The description reinforces max_chars truncation and gives endpoint examples, but it does not add substantial syntax or semantics beyond what the schema already provides.

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 states a specific verb and resource: a GET escape hatch for Loki read endpoints the other tools do not wrap. It also names concrete endpoints and explicitly distinguishes it from the named sibling tools, so an agent can identify when this generic request tool applies.

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?

It explicitly says to use this for read endpoints the other tools do not wrap and to prefer the named tools, which shape output. The examples of volume_range, format_query, alerts, and config clarify the intended fallback use.

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