What can you do with this server?

This server lets AI assistants query and analyze Graylog logs via MCP tools. * Search log messages with query strings, relative/absolute/keyword time ranges, stream filters, field selection, limit, and offset. * Search logs within a specific stream by providing a stream ID. * Run aggregations on log data, including count, average, sum, min, max, percentile, and other metrics, grouped by a field. * List all available Graylog streams. * Get details about a specific stream by ID. * Find streams by name. * Retrieve Graylog system information. * Quickly fetch recent error/critical logs with configurable hours and limit. * Count logs grouped by log level for recent time windows.

Which integrations are available for this server?

Enables integration with Graylog to query and analyze log data, providing tools for stream management, time-based filtering, and log statistics or aggregations.

How do I use MCP Graylog Server?

1. Click on "Install 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., "@MCP Graylog Server show me the error logs from the production stream for the last hour" 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.

MCP Graylog Server

by mothlike

Overview Schema Source Related Servers Score Discussions Admin

Python

Remote

MCP Graylog

MCP Graylog is a Model Context Protocol server for querying Graylog 6+ from AI assistants. The default transport is Codex stdio. Streamable HTTP is available only when you explicitly opt in for a remote, shared, or containerized runtime. The server uses MCP Python SDK 2.x and supports its current and legacy protocol revisions.

Install Dependencies

Use Python 3.11 or newer. If you are new to Python projects, the safest setup is to keep this server in its own virtual environment.

Install Python 3.11+ and uv.
On macOS with Homebrew:
```
brew install python@3.11 uv
```
If Python is already installed, you can install uv with pip:
```
python3 -m pip install --user uv
```
Create and activate a virtual environment from the repository root:
```
uv venv venv --python 3.11
source venv/bin/activate
```
Install the server dependencies:
```
uv pip install -e .
```
For development, tests, linting, and type checks, install the dev extras:
```
uv pip install -e ".[dev]"
```
Check that the command is available:
```
uv run mcp-graylog --help
```
If you installed the dev extras, run the test suite:
```
uv run pytest -q
```

Related MCP server: Graylog MCP Server

Quick Start: Codex Stdio

Install the project dependencies, then add this server to your Codex config:

[mcp_servers.graylog]
command = "uv"
args = ["run", "mcp-graylog"]

[mcp_servers.graylog.env]
GRAYLOG_ENDPOINT = "https://graylog.example.com"
GRAYLOG_TOKEN = "gl2-your-token"
MCP_SERVER_TRANSPORT = "stdio"

Run the command from this repository when Codex starts the MCP server:

uv run mcp-graylog

Token authentication with GRAYLOG_TOKEN is preferred. Legacy basic credentials are still supported by the runtime for older installations, but new setups should use a Graylog access token.

MCP Client Configuration Examples

All local client examples use stdio. Run them from this repository checkout, or replace uv with an absolute command that can start mcp-graylog in your environment.

Codex

Add this to ~/.codex/config.toml:

[mcp_servers.graylog]
command = "uv"
args = ["run", "mcp-graylog"]

[mcp_servers.graylog.env]
GRAYLOG_ENDPOINT = "https://graylog.example.com"
GRAYLOG_TOKEN = "gl2-your-token"
MCP_SERVER_TRANSPORT = "stdio"

Claude Code

For a project-shared server, add .mcp.json at the repository root:

{
  "mcpServers": {
    "graylog": {
      "type": "stdio",
      "command": "uv",
      "args": ["run", "mcp-graylog"],
      "env": {
        "GRAYLOG_ENDPOINT": "https://graylog.example.com",
        "GRAYLOG_TOKEN": "gl2-your-token",
        "MCP_SERVER_TRANSPORT": "stdio"
      }
    }
  }
}

Equivalent CLI setup:

claude mcp add-json graylog '{"type":"stdio","command":"uv","args":["run","mcp-graylog"],"env":{"GRAYLOG_ENDPOINT":"https://graylog.example.com","GRAYLOG_TOKEN":"gl2-your-token","MCP_SERVER_TRANSPORT":"stdio"}}'

Cursor

Add .cursor/mcp.json in the project, or ~/.cursor/mcp.json globally:

{
  "mcpServers": {
    "graylog": {
      "type": "stdio",
      "command": "uv",
      "args": ["run", "mcp-graylog"],
      "env": {
        "GRAYLOG_ENDPOINT": "https://graylog.example.com",
        "GRAYLOG_TOKEN": "gl2-your-token",
        "MCP_SERVER_TRANSPORT": "stdio"
      }
    }
  }
}

OpenCode

Add this to opencode.jsonc:

{
  "$schema": "https://opencode.ai/config.json",
  "mcp": {
    "graylog": {
      "type": "local",
      "command": ["uv", "run", "mcp-graylog"],
      "environment": {
        "GRAYLOG_ENDPOINT": "https://graylog.example.com",
        "GRAYLOG_TOKEN": "gl2-your-token",
        "MCP_SERVER_TRANSPORT": "stdio"
      },
      "enabled": true
    }
  }
}

Hermes

Add this to ~/.hermes/config.yaml:

mcp_servers:
  graylog:
    command: "uv"
    args: ["run", "mcp-graylog"]
    env:
      GRAYLOG_ENDPOINT: "https://graylog.example.com"
      GRAYLOG_TOKEN: "gl2-your-token"
      MCP_SERVER_TRANSPORT: "stdio"

Run /reload-mcp in Hermes after changing the file.

OpenClaw

Add this to ~/.openclaw/openclaw.json under mcp.servers, or use openclaw mcp set graylog '<json>' with the same server object:

{
  "mcp": {
    "servers": {
      "graylog": {
        "command": "uv",
        "args": ["run", "mcp-graylog"],
        "env": {
          "GRAYLOG_ENDPOINT": "https://graylog.example.com",
          "GRAYLOG_TOKEN": "gl2-your-token",
          "MCP_SERVER_TRANSPORT": "stdio"
        }
      }
    }
  }
}

Streamable HTTP

Use Streamable HTTP only when the server must be reachable from another process or host:

GRAYLOG_ENDPOINT="https://graylog.example.com" \
GRAYLOG_TOKEN="gl2-your-token" \
MCP_SERVER_ALLOWED_HOSTS="mcp.example.com,mcp.example.com:*" \
uv run mcp-graylog --transport streamable-http --host 0.0.0.0 --port 8000 --path /mcp

The equivalent environment setting is:

MCP_SERVER_TRANSPORT=streamable-http
MCP_SERVER_HOST=0.0.0.0
MCP_SERVER_PORT=8000
MCP_SERVER_PATH=/mcp
MCP_SERVER_DNS_REBINDING_PROTECTION=true
MCP_SERVER_ALLOWED_HOSTS=mcp.example.com,mcp.example.com:*
MCP_SERVER_ALLOWED_ORIGINS=https://app.example.com

MCP_SERVER_ALLOWED_HOSTS contains the exact hostnames accepted by the HTTP transport. Add both the bare hostname and hostname:* when clients may use an explicit port. For a direct IP deployment, use a value such as 192.0.2.10:*. Configure MCP_SERVER_ALLOWED_ORIGINS only for browser clients. To accept requests for any host behind a trusted reverse proxy, set MCP_SERVER_DNS_REBINDING_PROTECTION=false. This disables both Host and Origin validation and should not be used when the server is exposed directly.

Configuration

Variable	Required	Default	Description
`GRAYLOG_ENDPOINT`	yes	-	Base URL for Graylog, without embedded credentials.
`GRAYLOG_TOKEN`	yes for new setups	-	Preferred Graylog access token.
`GRAYLOG_VERIFY_SSL`	no	`true`	Verify TLS certificates.
`GRAYLOG_TIMEOUT`	no	`30`	Graylog HTTP timeout in seconds.
`MCP_SERVER_TRANSPORT`	no	`stdio`	`stdio` or `streamable-http`.
`MCP_SERVER_HOST`	no	`127.0.0.1`	Streamable HTTP bind host.
`MCP_SERVER_PORT`	no	`8000`	Streamable HTTP bind port.
`MCP_SERVER_PATH`	no	`/mcp`	Streamable HTTP MCP path.
`MCP_SERVER_DNS_REBINDING_PROTECTION`	no	`true`	Validate HTTP Host and Origin headers.
`MCP_SERVER_ALLOWED_HOSTS`	no	localhost values	Comma-separated allowed Host values.
`MCP_SERVER_ALLOWED_ORIGINS`	no	localhost values	Comma-separated allowed browser origins.
`LOG_LEVEL`	no	`INFO`	Server log level.

Graylog 6+ API Compatibility

The server uses the current Graylog Search Scripting and system APIs:

POST /api/search/messages
POST /api/search/aggregate
GET /api/streams
GET /api/streams/{stream_id}
GET /api/system

It does not use the legacy universal search API. Search payloads use query, timerange, streams, fields, size, and from.

MCP Tools

search_logs(search) searches messages with a typed MessageSearchInput.
search_stream_logs(stream_id, search) searches messages in one stream.
aggregate_logs(aggregation) runs grouped aggregations with AggregateLogsInput.
list_streams() returns available Graylog streams.
get_stream_info(stream_id) returns one stream definition.
search_streams_by_name(stream_name) filters streams locally by title.
get_system_info() returns Graylog system information.
get_error_logs(hours=1, limit=100) searches recent error and critical logs.
get_log_count_by_level(hours=1) aggregates recent logs by level.

Tool Input Examples

{
  "query": "level:ERROR",
  "timerange": {"value": 1, "unit": "h"},
  "streams": [],
  "fields": ["timestamp", "source", "level", "message"],
  "limit": 50,
  "offset": 0
}

{
  "query": "*",
  "timerange": {"keyword": "Last 24 hours"},
  "field": "source",
  "metric": "count",
  "limit": 10
}

{
  "stream_id": "000000000000000000000001",
  "search": {
    "query": "source:api",
    "timerange": {"value": 24, "unit": "h"},
    "fields": ["timestamp", "source", "message"],
    "limit": 25,
    "offset": 0
  }
}

Development

uv sync --extra dev
uv run pytest
uv run ruff check .

The package entrypoint is mcp-graylog, provided by mcp_graylog.cli:main.

Available Tools

9 tools

aggregate_logsD

ParametersJSON Schema

Name	Required	Description	Default
`aggregation`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Tool has no description.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Tool has no description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Tool has no description.

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

Purpose1/5

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

Tool has no description.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines1/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Tool has no description.

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

get_error_logsD

ParametersJSON Schema

Name	Required	Description	Default
`hours`	No
`limit`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Tool has no description.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Tool has no description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Tool has no description.

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

Purpose1/5

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

Tool has no description.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines1/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Tool has no description.

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

get_log_count_by_levelD

ParametersJSON Schema

Name	Required	Description	Default
`hours`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Tool has no description.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Tool has no description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Tool has no description.

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

Purpose1/5

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

Tool has no description.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines1/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Tool has no description.

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

get_stream_infoD

ParametersJSON Schema

Name	Required	Description	Default
`stream_id`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Tool has no description.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Tool has no description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Tool has no description.

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

Purpose1/5

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

Tool has no description.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines1/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Tool has no description.

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

get_system_infoD

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Tool has no description.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Tool has no description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Tool has no description.

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

Purpose1/5

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

Tool has no description.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines1/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Tool has no description.

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

list_streamsD

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Tool has no description.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Tool has no description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Tool has no description.

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

Purpose1/5

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

Tool has no description.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines1/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Tool has no description.

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

search_logsD

ParametersJSON Schema

Name	Required	Description	Default
`search`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Tool has no description.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Tool has no description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Tool has no description.

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

Purpose1/5

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

Tool has no description.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines1/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Tool has no description.

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

search_stream_logsD

ParametersJSON Schema

Name	Required	Description	Default
`search`	Yes
`stream_id`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Tool has no description.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Tool has no description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Tool has no description.

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

Purpose1/5

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

Tool has no description.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines1/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Tool has no description.

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

search_streams_by_nameD

ParametersJSON Schema

Name	Required	Description	Default
`stream_name`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Tool has no description.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Tool has no description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Tool has no description.

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

Purpose1/5

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

Tool has no description.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines1/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Tool has no description.

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.

9 tool updatesv0.2.0May 19, 2026
- First observedaggregate_logs
- First observedget_error_logs
- First observedget_log_count_by_level
- First observedget_stream_info
- First observedget_system_info
- First observedlist_streams
- First observedsearch_logs
- First observedsearch_stream_logs
- First observedsearch_streams_by_name

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

D1.7/5.0

Scored 2026-05-19 17:20 across 9 tools

Disambiguation3/5

Some tools have overlapping functionality, such as search_logs and search_stream_logs, or aggregate_logs and get_log_count_by_level, which could cause confusion. However, most tools target distinct resources or actions.

Naming Consistency3/5

Tools follow a snake_case pattern with verbs like get, list, search, aggregate. The pattern is mostly consistent but not perfectly uniform, e.g., list_streams vs get_stream_info.

Tool Count4/5

9 tools is appropriate for a Graylog server, covering the main read operations without being excessive. It feels well-scoped.

Completeness3/5

The set covers common query and retrieval operations but lacks write or management tools (e.g., create stream, update). It seems focused on read-only access, which may be intentional but is incomplete for full lifecycle.

Maintenance

ActivityMaintained

ResponsivenessSlow

Resources

GitHub Repository

Need Help?

Reddit Discussion

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Knowledge Grid
ai.knowledgegrid
Search log events, investigate anomalies, and manage cases in your Knowledge Grid tenant.
1
StreamScannerOAuth
net.streamscanner
Query your Twitch streams, events, supporters, raids & rankings from an AI assistant via OAuth.
Entertainment & Media Social Media
2
Auralogs
ai.auralogs
Read-only access to Auralogs production logs: search logs, inspect errors, review AI analyses.
Observability Monitoring
2
Foam Observability
io.github.foam-ai
Query application logs, traces, and metrics from your AI coding assistant via Foam's MCP server.
Observability Monitoring Developer Tools
2

Related MCP Servers

Graylog MCP Server
Monitoring Observability Search
PrinceGupta1999
A
license
Not graded
quality
B
maintenance
Enables AI assistants to query and analyze logs from Graylog instances using universal search with relative or absolute time windows, supporting both full result retrieval and lightweight count-only queries.
Updated 2 months ago (2026-07-04 07:27 UTC)
20
1
MIT
Graylog MCP Server
Monitoring Observability
abuzo
A
license
Not graded
quality
D
maintenance
Enables AI assistants to search and analyze logs in Graylog using three powerful tools: generic log search with Lucene queries, smart UUID/trace ID lookup across multiple fields, and stream-specific message retrieval with automatic field normalization.
Updated 10 months ago (2025-10-30 11:18 UTC)
13
MIT
graylog-mcp
Monitoring Observability
lcaliani
A
license
A
quality
C
maintenance
Enables querying Graylog log management system for messages using natural language, supporting multiple instances and flexible search parameters.
Updated 3 months ago (2026-05-29 14:34 UTC)
1
38
9
MIT
Graylog MCP Server
Observability Search
jagadeesh52423
A
license
A
quality
D
maintenance
An MCP server that gives AI assistants direct access to your Graylog logs -- search, aggregate, analyze, and cluster log data through natural language.
Updated 4 months ago (2026-05-11 11:58 UTC)
23
27
MIT