Skip to main content
Glama
igorolv

loki-mcp-server

exportLogs

exportLogs

Save matching Loki log lines from a selected time window to a local file, oldest first, by passing a LogQL query and optional start, end, format, and directory.

Instructions

Save matching log lines of a window to a local file, oldest first, when the user asks to save logs. Pass the same LogQL query as queryLogs, e.g. {app="backend"} |= "ERROR". Omit format to use the connection's default export format, which is raw unless the operator set a template; format="raw" keeps the lines returned by Loki, including any LogQL line_format stage; a template like "{time} {level:5} [{thread}] {logger} : {message}{stack}" rewrites them locally. Pass a user-specified directory directly; omit it for the default export directory. The answer gives the file path, the line count, and a start value to continue with when a limit stopped it.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
endNoWindow end. Default "now". Same formats as start.
queryYesLogQL log query, e.g. {app="backend"} |= "ERROR". Take label names and values from discoverLogs.
startNoWindow start, default now-1h. Examples: now-15m, now-2d, 2026-09-13T10:00:00+03:00.
formatNoOmit it for the connection's default export format (raw unless configured). "raw" forces the lines returned by Loki; a template with {time}, {level}, {service}, {logger}, {message}, {stack} and line fields like {thread} renders locally.
directoryNoLocal directory for the new file, e.g. C:\tmp\logs or incident-42. Omit it for the default export directory; a relative path is resolved under that directory. Configured exportRoots, if present, restrict destinations.
connectionYesConnection name from listConnections

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.6/5.0
Behavior4/5

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

Annotations only mark this as a non-readonly, non-idempotent, open-world write, so the description carries most of the burden and does well: it discloses the output artifact (file path, line count, start value), the default-format behavior, and that exportRoots restrict destinations. It does not say whether an existing file is overwritten or how the file is named, which is a residual gap.

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-loads the purpose and proceeds efficiently through query, format, directory, and return value with no filler. It is dense and slightly long, but each sentence contributes distinct information; only the format explanation runs a bit long.

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?

Covers the full calling contract despite having no output schema: it describes the return payload (path, line count, continuation start), the default behaviors for format and directory, and the security constraint (exportRoots). Nothing essential to calling it correctly is missing.

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 baseline is 3, but the description adds real meaning beyond the schema: the format default ('raw unless the operator set a template'), the semantics of raw vs template rewriting, and how a relative directory resolves under the export directory. Parameter interpretation is materially improved.

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?

Opens with a specific verb and resource ('Save matching log lines of a window to a local file') and adds the ordering guarantee ('oldest first'). It explicitly references the sibling queryLogs, so an agent can distinguish exporting from querying without opening either schema.

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 the explicit trigger ('when the user asks to save logs') and routes the agent to the correct query source by naming queryLogs ('Pass the same LogQL query as queryLogs'). It also names the continuation condition (limit stopped the export), which is actionable guidance.

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