Which integrations are available for this server?

Provides read-only access to Grafana Loki logs, allowing agents to query log labels, values, and recent logs via LogQL without exposing Loki's full API.

How do I use tiny-loki-mcp?

1. Click on "Deploy Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@tiny-loki-mcp show me recent logs from the web service" 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.

tiny-loki-mcp

by myers-gh1328

Overview Schema Source Related Servers Discussions Admin

TypeScript

Remote

tiny-loki-mcp

tiny-loki-mcp is a small read-only Model Context Protocol server for Grafana Loki. It exposes a narrow set of tools for agents that need to inspect recent logs without learning Loki's HTTP API.

Tools

loki_labels: list available label names.
loki_label_values: list values for one label.
loki_query: run a bounded LogQL range query.
loki_recent: fetch recent logs by optional host and service labels.

All tools are read-only. The server does not expose Loki delete, admin, or push APIs.

Related MCP server: Loki MCP Server

Configuration

Environment variables:

LOKI_URL: Loki base URL. Defaults to http://127.0.0.1:3100.
LOKI_MAX_LIMIT: maximum entries per query. Defaults to 500.
LOKI_MAX_LOOKBACK_SECONDS: maximum lookback window. Defaults to 86400.
LOKI_TIMEOUT_MS: HTTP request timeout. Defaults to 10000.

Run

npm install
npm run build
LOKI_URL=http://127.0.0.1:3100 node dist/index.js

MCP Client Example

{
  "mcpServers": {
    "tiny-loki": {
      "command": "node",
      "args": ["/path/to/tiny-loki-mcp/dist/index.js"],
      "env": {
        "LOKI_URL": "http://127.0.0.1:3100"
      }
    }
  }
}

Safety

The server caps query limits and lookback windows. It returns compact records with labels, timestamp, and line content instead of raw Loki responses.

Dependency Updates

Dependency updates are managed by Dependabot through .github/dependabot.yml. Dependabot opens weekly grouped PRs for npm and GitHub Actions updates. These PRs are never auto-merged; review and run the normal verification path before merge.

Releases

Releases use semantic versioning with vMAJOR.MINOR.PATCH tags. Release notes are tracked in CHANGELOG.md. Package publishing is not enabled.

License

MIT

Available Tools

4 tools

loki_labelsA

List Loki label names. Use this before querying when you need to discover available dimensions such as host, service, or level. This is read-only and returns only label names.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.5/5.0

Behavior4/5

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

The description states it is read-only and returns only label names, which clarifies its non-destructive nature and output scope. However, with no annotations, more detail on output format or limitations could be added.

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?

Two concise sentences, each adding value. The first sentence states the action, the second provides usage guidance and behavioral notes. No wasted words.

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?

For a tool with no parameters and no output schema, the description covers purpose, usage context, and behavior completely. Nothing else is needed.

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?

There are no parameters, so the description adds no parameter details. Baseline 4 is appropriate for a zero-parameter tool, and the schema coverage is 100% (trivially).

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 clearly states it lists Loki label names, which is the core purpose. It distinguishes from sibling tools like loki_label_values (which lists values for a label) and loki_query (queries logs).

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 explicitly advises using this before querying to discover dimensions like host, service, or level. It provides a clear use case but does not mention when not to use or alternative tools.

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

loki_label_valuesA

List values for one Loki label, such as host or service. Use this to discover valid filter values before running a log query. This is read-only.

ParametersJSON Schema

Name	Required	Description	Default
`label`	Yes	Label name to inspect, for example host, service, or level.

TDQS

A3.8/5.0

Behavior3/5

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

No annotations provided; description states 'This is read-only' which discloses the main behavioral trait. However, it does not cover potential issues like error handling or limits, leaving some gaps for a tool with no annotation support.

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?

Two concise sentences with no extraneous information. First sentence presents the action, second the usage context. Efficient and clear.

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?

Given the tool's simplicity (one parameter, no output schema, no annotations), the description covers purpose, usage, and read-only nature. It lacks details on return format but that is likely intuitive for a label value list.

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 already describes the parameter with examples. Description adds 'host or service' which reinforces but does not significantly add beyond schema coverage (100%). Baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly states 'List values for one Loki label' with examples (host, service), and relates to discovering filter values. It distinguishes from siblings like loki_labels (which likely lists labels), but does not explicitly differentiate.

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?

Explicitly states 'Use this to discover valid filter values before running a log query.' Provides clear when-to-use guidance. Does not mention when not to use or alternatives, but the context is sufficient.

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

loki_queryA

Run a bounded LogQL range query and return compact log records. Use this when you already know the LogQL selector or need text filters. Do not use this for unbounded or long-history searches; since and limit are capped by server configuration.

ParametersJSON Schema

Name	Required	Description	Default
`query`	Yes	Bounded LogQL query, for example {host="example"} \|= "error".
`since`	No	Lookback duration such as 30m, 2h, or 1d.	30m
`limit`	No	Maximum log entries to return.

TDQS

A4.6/5.0

Behavior4/5

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

No annotations provided, so description must carry the burden. It mentions that the query is bounded and that since and limit are capped, implying read-only behavior. However, it does not detail error handling, authentication requirements, or the exact response format beyond 'compact log records'.

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 extremely concise (two sentences) with no unnecessary words. The first sentence captures purpose and output, the second provides usage guidance. Every sentence earns its place.

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?

Given no output schema, the description explains the return value ('compact log records') but not its structure. The three parameters are all documented in the schema, and the description adds context about server caps. This is generally sufficient for a simple query tool, though more detail on the response format would improve completeness.

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%, but the description adds value by clarifying that since and limit are subject to server configuration caps, which is not in the schema. It also describes the output as 'compact log records', though the schema does not define output.

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 clearly states the verb 'Run', the resource 'bounded LogQL range query', and the output 'compact log records'. It effectively distinguishes from sibling tools like loki_labels and loki_recent by specifying that this tool is for LogQL queries with text filters.

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?

The description explicitly states when to use ('when you already know the LogQL selector or need text filters') and when not to use ('Do not use for unbounded or long-history searches'), and mentions server-side caps on since and limit. This provides clear decision support.

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

loki_recentA

Fetch recent logs by optional host and service labels. Use this for common troubleshooting when you do not need raw LogQL. At least one of host or service should normally be supplied to avoid broad queries.

ParametersJSON Schema

Name	Required	Description	Default
`host`	No	Optional host label to filter by.
`service`	No	Optional service label to filter by.
`since`	No	Lookback duration such as 30m, 2h, or 1d.	30m
`limit`	No	Maximum log entries to return.

TDQS

A3.8/5.0

Behavior2/5

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

No annotations provided, so description carries full burden. It lacks any behavioral details beyond the basic fetch operation, such as authentication requirements, rate limits, or potential side effects. For a read tool, stating it is non-destructive would have been helpful.

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?

Two sentences, no fluff. First sentence states purpose and key filters, second provides usage guidance. Efficiently front-loaded.

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 simple log fetch tool with good schema descriptions, the description covers key usage aspects. Lacks return format details, but overall adequate.

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 covers 100% of parameters with descriptions, so baseline is 3. The description adds value by advising that at least one of host or service should normally be supplied, but does not enhance understanding of since or limit beyond 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?

Clearly states the action ('Fetch recent logs') and the resource ('logs'), with optional filtering by host and service. Differentiates from sibling tools like loki_query by noting it avoids raw LogQL.

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?

Provides explicit guidance: use for common troubleshooting when raw LogQL is not needed. Advises supplying at least one of host or service to avoid broad queries. No explicit when-not-to-use or direct sibling comparison, but context is clear.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

4 tool updatesv0.1.0Jun 22, 2026
- First observedloki_label_values
- First observedloki_labels
- First observedloki_query
- First observedloki_recent

Deploy Server

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A4.2/5.0

Scored 2026-06-22 19:15 across 4 tools

Disambiguation5/5

Each tool serves a distinct purpose: label discovery, label value listing, LogQL query, and recent log retrieval. No overlap, making selection clear.

Naming Consistency5/5

All tool names follow the consistent pattern 'loki_<descriptive_noun>', with verbs implied (loki_labels > list labels, loki_query > run query). Perfect consistency.

Tool Count5/5

Four tools cover the essential Loki interactions for a lightweight server: discovery, querying, and troubleshooting. Neither too few nor too many.

Completeness4/5

Core operations for log exploration are present. Missing streaming or advanced filtering, but for a 'tiny' server, the surface is sufficient for common tasks.

Maintenance

ActivityStale

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Related MCP Connectors

Auralogs
ai.auralogs
Read-only access to Auralogs production logs: search logs, inspect errors, review AI analyses.
Observability Monitoring
2
logr A
it.logr
Query any public logr profile — timelines, events, full context — plus owner-authorized writes.
Social Media Knowledge & Memory
611
mcp A
com.googleapis.container
Provides read access to your GKE and Kubernetes resources.
Cloud Platforms Virtualization Monitoring
232
SuperlogOAuth
sh.superlog
Open-source agent that observes and fixes your application. Query logs, traces, metrics, incidents.
Monitoring Observability
21,039

Related MCP Servers

Grafana-Loki MCP Server
Monitoring Observability Databases
tumf
A
license
Not graded
quality
D
maintenance
Enables querying and formatting Loki logs from Grafana via the Model Context Protocol. It supports LogQL queries, label retrieval, and provides results in text, JSON, or markdown formats.
Updated 8 months ago (2026-01-05 04:26 UTC)
39 PyPI
29
MIT
Loki MCP Server
Observability Monitoring
mvs5465-test
F
license
Not graded
quality
D
maintenance
Enables AI models to query and analyze Kubernetes cluster logs through Grafana Loki, supporting semantic operations like error aggregation and pod restart detection. It provides tools for regex-based log searching and namespace discovery to facilitate natural language troubleshooting.
Updated 6 months ago (2026-03-28 00:58 UTC)
-
Loki MCP Server
Developer Tools Monitoring Observability
incu6us
A
license
A
quality
C
maintenance
An MCP server for querying Grafana Loki directly with a discovery-first workflow — labels, values, series, and LogQL queries without requiring Grafana.
Updated 5 days ago (2026-09-11 00:53 UTC)
5
6
MIT
LGTM MCP Server
Monitoring Observability
pokgak
A
license
Not graded
quality
C
maintenance
Provides read-only access to Loki, Prometheus, and Tempo APIs, enabling natural language queries for logs, metrics, and traces. Supports multiple instances and authentication via bearer tokens.
Updated 6 months ago (2026-03-13 06:45 UTC)
1
MIT