Provides tools for querying and analyzing logs from Grafana Loki, including tailing container logs, raw LogQL range and instant queries, listing containers/labels/values, discovering log patterns, and ranking log volume.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@loki-tail-mcp What is the proxy service saying?"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
An MCP server for Grafana Loki, designed around how LLMs actually query logs: compact output, hard row caps, and a fuzzy container-name rescue that turns the classic empty-result-because-wrong-name failure into an auto-corrected retry or an actionable suggestion list. Built on the Python MCP SDK (FastMCP); runs as a local stdio server or a containerized Streamable HTTP service with bearer auth.
Tool | Notes |
| "What is service X saying?" — the primary tool. Accepts approximate names: service vocabulary ( |
| Raw LogQL range query — multi-container correlation ( |
| Instant query at a point in time (metric queries). |
| Durable container names (ephemeral CI/batch names hidden). |
| Raw label discovery. |
| Log pattern mining — thousands of lines → ranked recurring templates with counts. Requires the server-side pattern ingester ( |
| Rank containers by log bytes over a window — "which service suddenly got noisy". |
| Fields Loki can auto-extract from a stream (name/type/cardinality/parser) — discover |
Matching always runs against live label values, never a hardcoded
list, so it survives renames. Resolution tries, in order: exact match →
alias vocabulary → substring both ways → typo distance (difflib). A
unique candidate is tailed automatically and flagged; multiple candidates
become a ranked suggestion list. Auto-generated container names
(docker/podman adjective_noun, hex-suffixed batch workers) are filtered
out of discovery and suggestions but stay queryable via raw LogQL.
The built-in alias vocabulary covers the common self-hosted stack
(vpn→gluetun, proxy→traefik, movies→radarr, …). Entries whose
targets don't exist in your fleet are inert; extend with your own via
LOKI_ALIASES.
Related MCP server: Loki MCP Server
// e.g. Claude Desktop claude_desktop_config.json / Claude Code .mcp.json
{
"mcpServers": {
"loki": {
"command": "uv",
"args": ["run", "--project", "/path/to/loki-tail-mcp", "loki-tail-mcp", "--stdio"],
"env": { "LOKI_URL": "http://your-loki-host:3100" }
}
}
}stdio mode has no network surface and skips bearer auth — the client owns the process.
The bundled Containerfile builds a Streamable HTTP server at /mcp
(stateless — restarts never strand client sessions). HTTP mode refuses
to start without MCP_BEARER_TOKEN; clients authenticate with
Authorization: Bearer <token>.
podman build -t loki-tail-mcp . # or: docker build -t loki-tail-mcp .
podman run -d --name loki-tail-mcp -p 8325:8325 \
-e LOKI_URL=http://your-loki-host:3100 \
-e MCP_BEARER_TOKEN=some-long-random-token \
loki-tail-mcploki_tail_mcp.healthcheck does a full HTTP round-trip to /mcp (the 401
counts as alive); wire it to your container healthcheck. Terminate TLS at
a reverse proxy — the server itself speaks plain HTTP.
Env var | Default | Purpose |
|
| Loki base URL. |
| (empty) | Sent as |
| (empty) |
|
|
| Upstream request timeout (s). |
|
| Row caps — Loki will happily return millions of rows; an MCP client will happily feed them to an LLM. Neither is what you want. |
| (empty) | Extra vocabulary merged over the built-ins: |
| (built-ins) | Comma-separated regexes marking names as ephemeral; replaces the defaults when set. |
|
| HTTP listen port. |
| (empty) | Required in HTTP mode; server refuses to start without it. Not used in |
# Full suite — mocked HTTP + pure resolution logic, no Loki needed
uv run --extra test pytest tests/ -vDiscover the fields Loki can auto-extract from a container's logs
(name, type, cardinality, parser — e.g. logfmt/json). Use this before
writing a LogQL parse stage in loki_query_range, e.g. finding that a
service logs logfmt with a status field enables
{container="x"} | logfmt | status>=500.
container: exact container name. minutes: window to sample. Default 60. limit: max fields. Default 20.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| minutes | No | ||
| container | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the behavioral transparency burden. It does disclose useful behavioral aspects: the tool samples a time window (minutes), returns fields with metadata (name, type, cardinality, parser), and is meant for pre-parse discovery. However, it does not explicitly state that it is a read-only operation or mention potential limitations (e.g., empty results, performance effects). This is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and well-structured. It opens with a one-sentence purpose, followed by a valuable usage example, then a succinct parameter list. Every sentence adds information without redundancy. The parameter formatting uses clear key: description pairs, making it easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (3 params, output schema present, no annotations), the description is nearly complete. It covers what the tool does, when to use it, how the output feeds into LogQL queries, and explains each parameter. Minor gaps include not stating behavior when no fields are found or prerequisites like the container must have recent logs, but these are not critical for basic use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description compensates well. Each parameter gets a meaningful explanation: 'container: exact container name', 'minutes: window to sample', 'limit: max fields'. It also clarifies defaults (60, 20). The example further demonstrates the container parameter's use in a query. This goes beyond the schema's bare titles and defaults.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Discover the fields Loki can auto-extract from a container's logs.' The verb 'Discover' and the specific resource (auto-extracted fields) distinguish it from sibling tools like loki_query_range or loki_list_labels. It also explains the output (name, type, cardinality, parser) and how it relates to creating parse stages.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage context: 'Use this before writing a LogQL parse stage in loki_query_range.' It includes a concrete example showing how to use the discovered fields in a query. However, it does not explicitly mention when not to use it or name alternative tools, though the sibling context and the 'fields' vs 'labels' distinction implicitly guide selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List durable container names actively logging in the lookback window.
Hides ephemeral noise — podman auto-names (adoring_neumann) and
hex-suffixed batch workers (transcode-ffmpeg-<hash>) number in the
thousands over 24h and would swamp the response. They remain queryable
via loki_query_range; use loki_list_label_values('container') for
the raw unfiltered list.
lookback: Duration (1h, 24h, 7d). Default 1h.
| Name | Required | Description | Default |
|---|---|---|---|
| lookback | No | 1h |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It honestly reveals that the tool filters out ephemeral names and explains why, plus notes that filtered items are still accessible via other tools. It does not mention error conditions or auth requirements, but for a simple list operation, the filtering behavior is the key nuance and is well covered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear main sentence, a brief explanatory note about filtering, and a concise parameter definition. Every sentence adds value without redundancy, and it remains compact while covering key details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one optional parameter) and the presence of an output schema, the description is complete. It covers the purpose, filtering behavior, lookback format, and alternative tools. No critical information for invocation or interpretation is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides only a `lookback` string with a default and no description. The description compensates fully by defining the parameter as a duration, providing example formats (`1h`, `24h`, `7d`), and restating the default. This gives the agent all necessary syntax and semantic meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action ('List') and specific resource ('durable container names actively logging in the lookback window'). It also distinguishes itself from siblings by mentioning that ephemeral names are filtered and pointing to `loki_list_label_values` for the raw unfiltered list, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly explains when to use this tool (for durable container names) and provides clear alternatives: ephemeral names remain queryable via `loki_query_range`, and raw unfiltered lists are available via `loki_list_label_values`. This gives the agent clear decision guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all label names Loki has seen in the given lookback window.
lookback: Duration (1h, 24h, 7d). Default 1h. Shorter is faster.
| Name | Required | Description | Default |
|---|---|---|---|
| lookback | No | 1h |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the burden. It implies a read-only listing operation and discloses performance behavior ('Shorter is faster'), but it does not mention potential result size, auth needs, or any side effects. This is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: the first states the tool's purpose, the second explains the parameter. No filler, front-loaded information, and every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple single-parameter listing tool with an output schema present, the description covers the essential behavior and parameter semantics. The sibling distinction is clear from the purpose statement, and no missing prerequisites or caveats are critical.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema only defines 'lookback' as a string with a default, giving no semantic detail. The description compensates fully by specifying valid examples ('1h', '24h', '7d'), the default, and the performance tradeoff. This adds significant meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'List all label names Loki has seen', which is a specific verb+resource statement. It clearly distinguishes this from the sibling tool loki_list_label_values, which lists values for a given label. The purpose is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context by stating the lookback window and the default ('Default 1h'), plus a practical performance hint ('Shorter is faster'). It does not explicitly mention alternatives or when not to use, but the usage context is clear enough for straightforward selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all values seen for a given label in the lookback window.
label: Label name (e.g. container, service_name, job, host).
lookback: Duration (1h, 24h, 7d). Default 1h.
| Name | Required | Description | Default |
|---|---|---|---|
| label | Yes | ||
| lookback | No | 1h |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It does disclose that results are limited to a lookback window and that values are 'seen' in that window, which adds context. However, it omits any detail about pagination, limits, ordering, or behavior when the label has no values. This is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: one purpose line followed by compact parameter documentation. Every sentence adds value, and the most important information is front-loaded. No filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity (2 params, no nested objects) and the presence of an output schema, the description covers the essential invocation details. However, it lacks usage context, alternative-tool differentiation, and behavioral caveats, making it only moderately complete for agent decision-making.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description fully compensates by explaining both parameters. It gives concrete examples for label ('container', 'service_name', etc.) and lookback ('1h', '24h', '7d') with the default value. This is more informative than the bare schema properties.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the operation: 'List all values seen for a given label in the lookback window.' It identifies the resource (label values) and the scope (lookback). It does not explicitly differentiate from sibling tools like loki_list_labels, but the wording is sufficiently specific to avoid major confusion.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives such as loki_list_labels, loki_query_range, or loki_patterns. The description does not mention exclusions, prerequisites, or typical use cases beyond the literal action.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Rank containers by log volume (bytes) — "which service suddenly got noisy". Leave container empty to rank the whole fleet; set it to scope to one container.
minutes: window to measure. Default 60. limit: max rows. Default 10.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| minutes | No | ||
| container | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden. It discloses the core behavior (ranking by bytes), the time window, the row limit, and the container scoping behavior. It doesn't mention anything contradictory, though it omits details like read-only nature or aggregation semantics, which are likely implied for a ranker.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, front-loaded with the primary action, and includes a compact parameter dictionary. Every sentence adds value, and there is no redundant filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with 3 optional parameters and an output schema, the description covers all necessary aspects: what it does, how to use parameters, and the use case. Nothing essential is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema descriptions are absent (0% coverage), but the description fully compensates by explaining all three parameters: container scope, minutes as the measurement window, and limit as max rows, including defaults. This adds meaning beyond the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Rank containers by log volume (bytes)' and provides a concrete use case ('which service suddenly got noisy'). It distinguishes itself from sibling tools like query/range or tail by focusing on volume ranking.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear guidance on when to use the tool and how to adjust scope: 'Leave container empty to rank the whole fleet; set it to scope to one container.' It doesn't explicitly mention alternatives or when not to use, but the use case is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Mine a container's recent logs into recurring patterns — the fastest
way to summarize what a noisy service is saying. One call turns
thousands of lines into a ranked list of templates (<_> marks the
variable parts) with occurrence counts.
container: exact container name (use loki_list_containers / loki_tail_container to find it). minutes: how far back to mine. Default 60.
Requires the Loki pattern ingester; only logs ingested after it was enabled are mined, so a small window right after enablement is normal.
| Name | Required | Description | Default |
|---|---|---|---|
| minutes | No | ||
| container | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the prerequisite of the Loki pattern ingester, the caveat that only logs ingested after its enablement are mined, and the output format (ranked templates with occurrence counts). This is excellent transparency beyond what annotations would provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized, front-loaded with the primary purpose, and each sentence adds value. The parameter explanations are integrated compactly without unnecessary fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given an output schema exists, the description does not need to detail return values. It covers the use case, prerequisites, parameter meanings, and output format, making it complete for a 2-parameter tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must explain parameters. It does: 'container: exact container name (use loki_list_containers / loki_tail_container to find it)' and 'minutes: how far back to mine. Default 60.' This fully compensates for the lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it 'Mine a container's recent logs into recurring patterns', using a specific verb and resource, and differentiates itself from sibling tools by summarizing noisy logs into templates. This is unique among the sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It describes the use case as 'the fastest way to summarize what a noisy service is saying' and tells users how to find the container name using sibling tools. However, it does not explicitly mention when not to use this tool (e.g., for raw log queries) versus alternatives, so it lacks explicit exclusionary guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run a LogQL instant query at a single point in time.
Best for metric queries like count_over_time({container="crowdsec"}[5m]).
For raw log search, prefer loki_query_range.
| Name | Required | Description | Default |
|---|---|---|---|
| time | No | now | |
| limit | No | ||
| query | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the instant, single-point-in-time behavior but does not mention return format, side effects, or permissions. The read-only nature is implied by 'query' but not explicitly stated, and the existing output schema mitigates missing return value details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, each adding value: the first defines the core action, the second gives a metric-query use case, and the third points to an alternative tool. No fluff or repetition, and the most important information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers purpose, an example, and alternative guidance, but with only 3 parameters and zero schema descriptions, it leaves the agent without enough detail on parameter semantics. The output schema covers return values, so that is not a gap, but parameter documentation remains thin.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero description coverage for parameters. The description provides an example query for the `query` parameter but does not explain the `time` (e.g., format, default 'now') or `limit` (e.g., max results) parameters. Given the low schema coverage, the description should have compensated more thoroughly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Run') and resource ('LogQL instant query') with a clear temporal scope ('at a single point in time'). It also distinguishes from the sibling tool `loki_query_range` by explicitly recommending the latter for raw log search.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use this tool: 'Best for metric queries' with a concrete LogQL example. It also names the alternative for raw logs ('prefer `loki_query_range`'), covering both use and non-use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run a LogQL range query against Loki.
query: LogQL expression, e.g. {container="nginx"} |= "ERROR"
or a metric query like rate({container="traefik"}[5m]).
start: Duration back from now (15m, 2h, 3d), RFC3339 timestamp,
or ns-since-epoch. Default 1h.
end: Same format as start. Default now.
limit: Max log lines to return (clamped to server max, default 100).
direction: backward (newest first) or forward. Default backward.
Returns compact timestamp [labels] message lines, newest first. For
metric queries returns {labels} ts:val ts:val ... per series.
| Name | Required | Description | Default |
|---|---|---|---|
| end | No | now | |
| limit | No | ||
| query | Yes | ||
| start | No | 1h | |
| direction | No | backward |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses defaults for start/end/direction, limit clamping, and the return format for both log and metric queries. It doesn't mention auth or rate limits, but these are not critical for a query tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured, with each parameter on its own line and a separate return format explanation. It is concise yet complete, with no redundant or filler content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 5 parameters and no annotations, but the description covers all parameters, defaults, output formats, and provides query examples. It is complete enough for an agent to select and invoke the tool correctly without further clarification.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description fully compensates by explaining each parameter: query syntax, start/end formats (duration, RFC3339, ns epoch), limit handling, and direction semantics with defaults. This adds substantial meaning beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Run a LogQL range query against Loki' with concrete examples, clearly distinguishing this range query tool from the instant query sibling. The verb and resource are specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context for when to use this tool (querying over a time range) and explains behaviors like defaults and return formats. It doesn't explicitly name alternatives or exclusions, but the range query nature and parameter details imply appropriate usage versus instant queries or tailing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tail the most recent log lines for a single container.
container: Container name (e.g. nginx, traefik, arr-sonarr).
Exact names work best; an unknown name is resolved against
live container names (service vocabulary like vpn works) —
a unique match is tailed automatically and flagged in the
output, otherwise candidate names are returned.
minutes: How far back to look. Default 15.
limit: Max lines to return. Default 200.
filter: Optional substring filter applied as LogQL |= "filter".
Case-sensitive. Leave empty for no filter.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| filter | No | ||
| minutes | No | ||
| container | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the behavioral burden. It discloses that partial container names are resolved against live containers, that a unique match is automatically tailed and flagged, and that ambiguous matches return candidates. It also notes filter case-sensitivity and application of LogQL, which are important behavioral details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and uses a clear per-parameter layout for scannability. Each sentence provides necessary information—no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema, the description need not explain return values. It covers parameter semantics, resolution behavior, and filter mechanics, making the tool fully operational from the description alone. The behavioral disclosures about candidate returns and flagging round out the context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description documents each parameter meaningfully: container name resolution with examples, minutes default, limit default, and filter semantics (LogQL substring, case-sensitive). This adds substantial value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a clear verb ('Tail') and resource ('most recent log lines for a single container'), immediately distinguishing it from sibling Loki query tools. The tool's scope is explicitly limited to a single container, which separates it from list and query tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains the intended use case for tailing logs and provides essential context for the container parameter (exact names vs. fuzzy resolution). It does not explicitly mention when to use an alternative like loki_query_range, but the usage context is unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0loki_detected_fieldsloki_list_containersloki_list_label_valuesloki_list_labelsloki_log_volumeloki_patternsloki_query_instantloki_query_rangeloki_tail_containerScored across 9 tools
Each tool has a clearly distinct purpose. The two query tools (instant vs range) are explicitly differentiated in their descriptions, and the discovery/analysis tools (labels, patterns, volume, fields, containers) do not overlap. Even tail_container is clearly a convenience wrapper for a specific use case.
Six of nine tools follow a consistent loki_verb_noun pattern (query_instant, query_range, tail_container, list_labels, list_label_values, list_containers). Three tools (patterns, log_volume, detected_fields) use noun phrases, breaking the verb-first convention. This is a minor inconsistency that doesn't hinder usability.
Nine tools is a well-scoped number for a Loki exploration server. Each tool serves a distinct purpose without redundancy, covering querying, metadata discovery, log analysis, and container navigation. The count is neither too small nor overwhelming.
The tool set covers the full range of Loki interactions: instant queries, range queries, metadata discovery (labels, values), container listing and tailing, pattern mining, volume ranking, and field detection for parsing. There are no obvious gaps for a read-only log exploration workflow.
MCP server for building and testing AI agents with multi-model experimentation and insights.
The Remote MCP server acts as a standardized bridge between LLM applications (like Claude, ChatGPT, and Cursor) and external services, enabling AI agents to access external tools and resources. Its primary capability is providing a centralized search tool to discover other MCP servers and their respective tools. Unlike local implementations, it runs remotely with OAuth authentication and permission controls for security.
Query application logs, traces, and metrics from your AI coding assistant via Foam's MCP server.
The Grafbase MCP server sits in front of a GraphQL API and exposes an MCP protocol-compliant interface that allows AI agents and LLMs to explore and query GraphQL APIs using natural language. It provides tools to search schemas, introspect types and fields, and execute GraphQL queries while minimizing context bloat by returning only relevant schema subsets, with built-in support for authentication, authorization, and configurable access control.
