mcp-loki

Loki: Get Log Context

loki_get_log_context

Read-only

Retrieves the log lines surrounding a specific Loki entry, showing what a stream logged just before and after it. Use it to inspect the context around an error or event without filtering out nearby lines.

Instructions

Show the lines around one log line — what the same stream logged just before and after it, unfiltered — the way Grafana's 'show context' does. Pass the stream selector (built from the line's common_labels plus its own labels, e.g. {namespace="payments", pod="api-7d9f-x2k4"}) and the line's exact ts. Lines come back oldest first, with the anchor line marked anchor: true.

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>",
      "time": "<time>"
    },
    "name": "loki_get_log_context"
  }
}

Input Schema

Name	Required	Description	Default
`time`	Yes	The anchor line's `ts` exactly as returned (e.g. 2026-11-03T22:13:37.968458546Z), or its nanosecond timestamp. Any other time form is accepted too.
`after`	No	Lines to show after the anchor (0-500). Defaults to 10.
`before`	No	Lines to show before the anchor (0-500). Defaults to 10.
`window`	No	How far to look on each side for those lines, as a duration (5m, 1h). Defaults to 1h; a quiet stream may need more.	1h
`selector`	Yes	Stream selector for the line's stream, e.g. `{namespace="payments", pod="api-7d9f-x2k4", container="api"}`. Matchers only; the narrower, the more the context is that one process's.
`hide_labels`	No	Stream labels to leave out of the answer. Defaults to ["filename"], which on Kubernetes is a 120-character /var/log/pods/... path repeating namespace, pod and container. Pass [] to see every label.
`parsed_fields`	No	Include the labels extracted by \| json, \| logfmt, \| regexp or \| pattern on each line, under `fields`. Off by default because they restate the line itself and double its size; turn it on after line_format or keep has reshaped the line, or to read a nested JSON value flattened. Structured metadata (trace_id, detected_level) is always included.
`max_line_chars`	No	Cut each line at this many characters (80-100000); a cut line ends with `… [+N chars]`. Defaults to 2000. Some services log single lines of hundreds of KB.

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.2.0Nov 6, 2026

TDQS

A4.3/5.0

Behavior4/5

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

With readOnlyHint and openWorldHint already declared, the description still adds real value: results are unfiltered, returned oldest-first, and the anchor line is flagged `anchor: true`. It does not say what happens when the window yields no lines or how many lines come back by default, which matters for a context tool with no output schema.

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?

Front-loaded with the purpose in the first clause, then invocation, then return shape — every sentence carries information and no schema detail is redundantly restated. The dense em-dash phrasing is readable but slightly packed for a first read.

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 an 8-parameter read tool with no output schema, the description covers purpose, the two required inputs, and key return characteristics (ordering, anchor marker). Gaps are edge behavior — empty windows, default result counts — which keep it from being fully complete.

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?

Schema coverage is 100%, so the baseline is 3; the description goes slightly beyond by explaining how to construct the selector (common labels plus the line's own labels, with a concrete payments example) and by emphasizing the exactness of `ts`, which is the most common failure mode. Everything else about before/after/window is left to the already-detailed schema.

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 — 'Show the lines around one log line' — and immediately scopes it ('what the same stream logged just before and after it, unfiltered'), which distinguishes it from the query siblings that take a query rather than an anchor timestamp. The Grafana 'show context' analogy and the required anchor `ts` make the operation unambiguous.

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?

Explains how to invoke it (pass the stream selector derived from common_labels plus the line's own labels, plus the exact `ts`) and ties the concept to a familiar Grafana feature. It does not explicitly name an alternative such as loki_query_logs and when to prefer it, so there is no true when-not-to-use guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server