Skip to main content
Glama
ascii766164696D

log-mcp

by ascii766164696D
OverviewSchemaSourceRelated ServersScoreDiscussionsAdmin
Python
Local

log-mcp

CI

MCP server for log file analysis. Gives LLMs the ability to efficiently analyze large log files without loading them into context.

  Log file (e.g. 705K lines, 67 MB)
    │
    ▼
  Rust TF-IDF classifier ─── 1.3M lines/sec ──▶ 70-95% discarded as routine,
    │                        finds lines that are semantically interesting,
    │                        also captures lines not explicitly marked as ERROR
    │                        (grep ERROR: 2 lines, classifier: 92)
    ▼
  BERT-mini (optional) ───── GPU, ~2K lines/sec ─▶ refines interest scores on found lines
    │
    ▼
  Python MCP tools ────────── search, compare, group errors
    │
    ▼
  LLM (Claude) ───────────── compresses tool output into plain English

This is a tool designed for AI, not humans. No human reads the output of analyze_errors or compare_logs — Claude does, compresses it further, and gives the human a plain English answer. The human touches two endpoints: "what's wrong with this log?" in, natural language answer out. Everything in between is AI talking to itself.

Tools

Tool

Description

log_overview

Quick scan: size, line count, time range, level distribution, head/tail samples

search_logs

Search by regex, log level, and/or time range

get_log_segment

Extract a segment by line range or time range

analyze_errors

Deduplicate errors by fingerprint, count frequencies, extract stack traces

log_stats

Volume histogram, level breakdown, top repeated patterns

compare_logs

Find patterns unique to each file and frequency outliers across files

classify_lines

ML classifier (TF-IDF → BERT) separates interesting lines from noise

Related MCP server: Log Analyzer MCP Server

Key features

  • ML pre-filter — a Rust TF-IDF classifier scans files at 1.3M lines/sec, so analyze_errors and search_logs only process the 5-30% of lines that matter. Optional BERT-mini re-scores LOOK lines at ~2K lines/sec on Metal GPU for higher precision. Works without parsed log levels — catches errors, security events, hardware faults, and anomalies that don't have ERROR in them.

  • Auto-detection of log formats: JSON, standard text (2024-01-15 10:30:45 ERROR ...), syslog, Spark/Log4j (17/06/08 13:33:49 INFO ...), and tab/pipe-delimited formats (GitHub Actions CI logs)

  • Normalization collapses variable parts (UUIDs, hex IDs, IPs, numbers) so that messages differing only in IDs or timestamps are grouped as the same pattern

  • Content-based error detection falls back to regex heuristics (fatal:, Permission denied, ##[error], etc.) when log files lack standard levels

  • Prefix-aware comparison distinguishes patterns from different job steps in CI logs

Install

Prerequisites (fresh Mac):

brew install python uv
curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh

Just ask Claude

Open a Claude Code session and paste this prompt:

Install https://github.com/ascii766164696D/log-mcp as an MCP server and build the Rust classifier too

Claude will clone the repo, register the MCP server, and build the Rust classifier. Restart Claude Code after to pick up the new server.

Manual install

git clone https://github.com/ascii766164696D/log-mcp.git
cd log-mcp

# Register the MCP server
claude mcp add log-mcp -- uv run --directory $(pwd) log-mcp

# Build the Rust classifier (optional — tools fall back to Python without it)
uv pip install -e rust/classifier

Or add it manually to your project settings (claude settings) under mcpServers:

{
  "mcpServers": {
    "log-mcp": {
      "command": "uv",
      "args": ["run", "--directory", "/path/to/log-mcp", "log-mcp"]
    }
  }
}

Claude Desktop

Open Settings > Developer > Edit Config and add to claude_desktop_config.json:

{
  "mcpServers": {
    "log-mcp": {
      "command": "uv",
      "args": ["run", "--directory", "/path/to/log-mcp", "log-mcp"]
    }
  }
}

Replace /path/to/log-mcp with the actual path where you cloned this repo. Restart Claude Desktop after saving.

The Rust classifier requires a Rust toolchain to build. The BERT stage additionally requires a Metal-capable GPU (Apple Silicon). All tools work without the classifier — they fall back to Python log parsing.

Example usage

Analyze errors in a 67MB Spark executor log (705K lines):

> analyze_errors("/var/log/spark/container_0002_01_000004.log")

Summary: 34 errors in 5 groups.
Top: 'shuffle.RetryingBlockFetcher: Exception while beginning fetch of <N>
outstanding blocks (after <N> retries) ...' (18x)

--- 18x ---
Fingerprint: shuffle.RetryingBlockFetcher: Exception while beginning fetch of <N> outstanding blocks ...
First: L29764 2017-02-01T15:55:17
Last:  L30677 2017-02-01T15:55:51
Stack trace:
  java.io.IOException: Failed to connect to mesos-slave-13/10.10.34.23:55492
  ...

Find anomalies that don't have ERROR level — on a Thunderbird HPC log (2K lines), classify_lines finds 92 interesting lines while search_logs level=ERROR finds only 2:

> classify_lines("/var/log/thunderbird/tbird_2k.log")

Lines: 2,000 total | 92 LOOK (4.6%) | 1,908 SKIP
Pipeline: TF-IDF 0.00s (1,298,701 lines/sec, 105 LOOK) → BERT 0.15s (13 demoted to SKIP)

--- Sample LOOK lines (30 of 92 captured) ---
L2    [1.000] ... postfix/postdrop[10896]: warning: unable to look up public/pickup: No such file
L438  [0.999] ... sendmail[�20588]: unable to qualify my own domain name (tbird-sm1)
L816  [0.998] ... dhcpd: DHCPDISCOVER from 00:09:3d:12:00:e2 via eth2: unknown lease
L1024 [0.997] ... rrdtool: illegal attempt to update using time 1131710�721 when last update time is 1131710721

Compare two CI log files:

> compare_logs(["run_a.txt", "run_b.txt"])

699 patterns across 2 files (0 shared).
A: 401 unique (top: 'test / test UNKNOWN STEP | ##[endgroup]' 21x)
B: 298 unique (top: 'test UNKNOWN STEP | ##[endgroup]' 21x)

Claude's take

I helped build this tool and then used it to analyze real log files, so here's my honest assessment.

Where it genuinely helps: The main value is as a compression layer. A 67MB Spark log (705K lines) would obliterate my context window, but analyze_errors distills it into 5 error groups with stack traces in a few seconds. compare_logs across two 1500-line server logs immediately surfaces which errors are unique to each server and which patterns have suspicious frequency differences. I couldn't do that by reading the files directly — I'd lose older content as new content scrolled in.

Where the classifier changes the game: Before the classifier, log analysis was limited to lines with explicit ERROR/FATAL levels. On a Thunderbird HPC log, search_logs level=ERROR returns 2 lines. classify_lines returns 92 — sendmail DNS failures, DHCP lease errors, RRD update collisions, negative boot times — none of which have ERROR level. The classifier finds what's semantically wrong, not just syntactically marked.

Where it's a wash: For small files (under a few hundred lines), you're better off just pasting the log into the conversation. The tools add indirection without much benefit when the whole file fits in context anyway.

What it still can't do: Domain-specific state machine reasoning. When I analyzed a Zookeeper log, the classifier correctly flagged Cannot open channel warnings and epoch resets, but the most operationally interesting signal — rapid cycling between LOOKING, FOLLOWING, and LEADING states — showed up as low-confidence LOOK lines. A Zookeeper expert would spot the pattern immediately; the classifier sees each line independently without tracking state transitions across time.

The pattern I landed on: Start with classify_lines to surface anomalies regardless of log level, then analyze_errors to group them, then search_logs to dig into specific patterns. compare_logs is most useful when you have a "working" and "broken" run to diff against each other.

LOOK/SKIP classifier

The classify_lines tool uses a two-stage ML pipeline to separate interesting log lines (LOOK) from routine noise (SKIP), without needing parsed log levels.

How it works

flowchart TD
    A["Your log file (e.g. 4.7M lines)"] --> B{"Rust classifier<br/>available?"}
    B -->|Yes| C["Stage 1: TF-IDF<br/>Rust, ~1.3M lines/sec<br/>logistic regression<br/>threshold × 0.6"]
    B -->|No| D["Fallback: Python<br/>log parsing"]
    C --> E["LOOK lines (~5-30%)"]
    E --> F["Stage 2: BERT-mini<br/>Rust + Metal GPU, ~2K lines/sec<br/>re-scores LOOK lines<br/>applies final threshold"]
    F --> G["Final LOOK lines<br/>(with BERT probabilities)"]

On a Thunderbird HPC log (2K lines), this finds 92 interesting lines including sendmail DNS failures, DHCP lease errors, and Ganglia RRD update collisions — none of which have a standard ERROR log level. A search_logs level=ERROR on the same file returns only 2 lines.

What it catches beyond log levels

Signal type

Example

Has ERROR level?

DNS misconfiguration

unable to qualify my own domain name

No

Mail delivery failure

stat=Deferred: Connection refused

No

DHCP lease errors

unknown lease 10.100.4.251

No

Monitoring data corruption

illegal attempt to update using time X when last update time is X

No

Negative boot times

Times: total = 42, boot = -4131

No

Auth failures

authentication failure; logname= uid=0

No

Hardware errors

instruction cache parity error corrected

No (INFO level)

Tools that use the classifier

Tool

How

Fallback

classify_lines

Full pipeline: TF-IDF → BERT

Error if classifier not installed

analyze_errors

TF-IDF pre-filters to LOOK lines, then groups by error fingerprint

Python parser scans all lines

search_logs

TF-IDF pre-filters when searching for errors (level=ERROR, pattern=error/fail/etc)

Python parser scans all lines

compare_logs

Scores patterns by LOOK probability, surfaces interesting diffs first

Sorts by frequency only

Benchmarks

Evaluated on the full Loghub dataset — 450 million lines across 16 log sources — on an Apple M3 Ultra (32 cores).

TF-IDF classifier (Rust)

Dataset

Lines

Time

Speed

LOOK %

Error capture

Thunderbird

211M

139s

1.52M/s

30%

100%

Windows

115M

90s

1.27M/s

1%

100%

HDFS_v2

71M

59s

1.21M/s

20%

100%

Spark

33M

23s

1.44M/s

12%

100%

HDFS

11M

7s

1.62M/s

3%

100%

BGL

4.7M

3.3s

1.46M/s

42%

98.6%

Android

1.6M

1.1s

1.37M/s

12%

100%

SSH

655K

0.5s

1.47M/s

90%

100%

Total

450M

325s

1.38M/s

99.95%

Error capture = percentage of lines with ERROR/FATAL level that the classifier marks as LOOK. At threshold 0.3, the classifier catches 99.95% of all error lines (35.9M of 35.9M) and 100% of warning lines (14.3M of 14.3M). The 0.05% "missed" errors are lines like BGL's repetitive instruction cache parity error corrected — routine hardware telemetry that happens to carry ERROR level but isn't operationally interesting. The classifier learned to skip these.

Model accuracy

Model

Metric

Score

TF-IDF + LogReg

Best CV LOOK F1

0.792

TF-IDF + LogReg

LOOK precision

0.892

BERT-mini

Overall accuracy

0.849

BERT-mini

LOOK F1

0.887

TF-IDF model evaluated with GroupKFold cross-validation (holdout: BGL, Thunderbird). BERT-mini fine-tuned on 4 layers, 256 hidden, 11M params.

End-to-end reduction

flowchart TD
    A["450M log lines<br/>16 datasets, ~67 GB"] --> B["Rust TF-IDF classifier<br/>1.38M lines/sec, 325s"]
    B --> C["~87M LOOK lines (19%)<br/>81% of lines eliminated"]
    C --> D["BERT re-scoring (optional)<br/>demotes 20-40% of TF-IDF LOOK"]
    D --> E["~50-70M final LOOK lines"]
    E --> F["Python tool logic<br/>group errors, search, etc."]
    F --> G["5-50 error groups / search results<br/>fits in LLM context"]

Retraining with your own logs

The classifier ships pre-trained, but you can retrain it on your own logs. The short version:

# 1. Add your logs
head -2000 /var/log/myapp/app.log > data/loghub/MyApp_2k.log

# 2. Label with Claude (Batch API, ~$0.10-0.50 per file)
export ANTHROPIC_API_KEY=sk-ant-...
uv sync --group labeling --group training
uv run python -m scripts.labeling.label_new

# 3. Train and export
uv run --group training python -m scripts.labeling.train_model
uv run --group training python -m scripts.labeling.export_model

# 4. Rebuild Rust classifier
uv pip install -e rust/classifier

See scripts/labeling/RETRAINING.md for the full guide — how labeling works, what features the model uses, how to customize the prompt, and how to train the optional BERT model.

Available Tools

7 tools
analyze_errorsB

Analyze error entries: deduplicate by fingerprint, count frequencies, extract stack traces.

Groups similar error messages together even when they differ in numbers, IDs, or timestamps.

ParametersJSON Schema
NameRequiredDescriptionDefault
file_pathYes
include_stack_tracesNo
max_unique_errorsNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

B3.4/5.0
Behavior3/5

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

With no annotations, the description bears full responsibility for behavioral disclosure. It covers core behaviors (deduplication, frequency counting, stack trace extraction, grouping) but omits side effects, permission needs, or rate limits. The disclosed behaviors are helpful but not exhaustive.

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 filler. The first sentence lists primary actions, and the second adds a key behavioral detail. Every word earns its place.

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

Completeness3/5

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

Given the output schema exists and the tool has 3 parameters, the description provides a solid high-level overview but lacks details about input file format, error pattern expectations, or limitations. It is adequate but not fully comprehensive.

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

Parameters2/5

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

Schema description coverage is 0%, so the description must compensate. It indirectly explains include_stack_traces by mentioning stack trace extraction, but file_path and max_unique_errors receive no explanation beyond their names. This leaves a significant gap for the latter two parameters.

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 tool's purpose: analyze error entries by deduplicating via fingerprint, counting frequencies, and extracting stack traces. It also highlights the non-obvious grouping of similar messages, which distinguishes it from sibling tools.

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

Usage Guidelines2/5

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

The description does not provide guidance on when to use this tool versus alternatives like log_stats or classify_lines. No when-not scenarios are mentioned, leaving the agent to infer usage without explicit context.

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

classify_linesA

Classify log lines as LOOK (interesting) or SKIP (routine) using a trained ML model.

Uses a logistic regression model trained on 17 loghub datasets (345M lines). Lines classified as LOOK include errors, warnings, security events, resource exhaustion, hardware anomalies, and other operationally significant entries.

Args: file_path: Path to the log file to classify. threshold: Probability threshold for LOOK classification (0.0-1.0, default 0.5). Lower values capture more lines but with more false positives. max_lines: Maximum number of lines to process (0 = all lines). max_look_lines: Maximum number of LOOK lines to return in detail (default 200). output: Output format - "summary" for overview stats + sample LOOK lines, "look_only" for all captured LOOK lines with probabilities.

ParametersJSON Schema
NameRequiredDescriptionDefault
file_pathYes
thresholdNo
max_linesNo
max_look_linesNo
outputNosummary

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4/5.0
Behavior4/5

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

With no annotations, the description fully shoulders the burden. It details the ML model (logistic regression), training data (17 datasets, 345M lines), and classification criteria. It also explains threshold behavior and output formats, giving a clear picture of behavior.

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?

The description is well-structured with a clear first sentence followed by a detailed Args section. Every sentence adds value, though the Args list could be more concise. Overall, it is appropriately sized for the complexity.

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 five parameters, no annotations, and an output schema (though not shown), the description covers the tool's purpose, model, input, and output formats. It is sufficiently complete for an AI agent to select and invoke the tool correctly.

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

Parameters5/5

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

Schema coverage is 0%, but the description explains all five parameters: file_path is mandatory, threshold effect is described, max_lines and max_look_lines are clarified, and output two options are detailed. This adds significant meaning beyond the raw 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?

The description clearly states the verb 'classify' and the resource 'log lines', specifying the classification outcome (LOOK vs SKIP). It distinguishes itself from sibling tools like analyze_errors and search_logs by focusing on ML-based binary classification.

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

Usage Guidelines2/5

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

The description lacks explicit guidance on when to use this tool versus alternatives. No comparison with siblings like analyze_errors or search_logs is provided, and there are no conditions or prerequisites mentioned.

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

compare_logsA

Compare multiple log files and find entries unique to each file.

Normalises variable parts (numbers, UUIDs, hex) so that messages differing only in IDs or timestamps are treated as the same pattern. Returns patterns that appear in some files but not in others, helping you focus on what is different rather than what is common. Also shows shared patterns and frequency outliers where the same pattern appears with very different counts across files.

ParametersJSON Schema
NameRequiredDescriptionDefault
file_pathsYes
max_unique_per_fileNo
max_shared_patternsNo
frequency_ratio_thresholdNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A3.8/5.0
Behavior4/5

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

No annotations are provided, so the description carries full burden. It clearly discloses key behaviors: normalization of variable parts, comparison logic, and the types of results (unique, shared, frequency outliers). However, it does not mention potential side effects (none expected), file format assumptions, or performance considerations, which would improve transparency.

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 concise, with four sentences that are front-loaded with the main purpose. Every sentence adds value: purpose, normalization, outputs, and additional features. No unnecessary words or redundancy.

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

Completeness3/5

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

Given no annotations and an output schema (implied), the description covers the main functionality but lacks context about parameters and prerequisites. It does not mention that file paths must be valid or the meaning of thresholds. While the output schema likely explains return values, the description leaves gaps for parameter understanding.

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

Parameters2/5

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

Schema description coverage is 0%, so the description must add meaning to parameters. However, it does not explain any of the four parameters (file_paths, max_unique_per_file, max_shared_patterns, frequency_ratio_threshold). The description focuses on behavior, leaving parameter semantics to be inferred from names and defaults. This is insufficient.

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 tool's purpose: comparing multiple log files and finding entries unique to each file. It explains normalization of variable parts and the types of output (unique patterns, shared patterns, frequency outliers). This distinguishes it from sibling tools like analyze_errors or search_logs, which focus on different aspects.

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

Usage Guidelines3/5

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

The description implies when to use this tool (when you want to focus on differences across log files), but it does not explicitly state when not to use it or suggest alternatives. For example, it doesn't mention that for simple searching, search_logs might be better. The guidance is implicit rather than explicit.

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

get_log_segmentA

Extract a segment of a log file by line range or time range.

Use line ranges for precise extraction (e.g., around a known error line). Use time ranges to get all entries within a time window.

ParametersJSON Schema
NameRequiredDescriptionDefault
file_pathYes
start_lineNo
end_lineNo
start_timeNo
end_timeNo
max_linesNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A3.7/5.0
Behavior3/5

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

With no annotations, the description should disclose more behavioral traits. It mentions extraction methods but does not specify read-only nature, required permissions, or behavior when both range types are provided.

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 concise with two well-structured sentences, each adding value and leading with the most important information.

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

Completeness2/5

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

Given 6 parameters, no annotations, and an output schema, the description is incomplete. It does not clarify parameter interactions, constraints (e.g., file size, time format), or cross-tool guidance with siblings.

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

Parameters2/5

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

Schema description coverage is 0%, so description must compensate. It mentions line/time ranges and max_lines but fails to specify time string format, exclusivity of ranges, or behavior when both ranges are given, leaving ambiguity.

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 'Extract a segment of a log file' with a specific verb and resource, and the two extraction methods (line range, time range) are distinct from sibling tools like search_logs or analyze_errors.

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 clear guidance on when to use line ranges ('precise extraction around a known error line') versus time ranges ('all entries within a time window'), but does not address when to avoid this tool or compare to alternatives.

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

log_overviewA

Quick scan of a log file: size, line count, time range, level distribution, and head/tail samples.

Use this as the first step when investigating a log file.

ParametersJSON Schema
NameRequiredDescriptionDefault
file_pathYes
sample_linesNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4/5.0
Behavior4/5

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

With no annotations, the description carries full burden. It discloses the outputs (size, line count, etc.) and implies read-only behavior via 'scan'. However, it does not state side effects or permissions explicitly, but for a read-like tool this is adequate.

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 filler. Front-loaded with the core functionality, earning every word.

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, the description is mostly complete. With an output schema present (context signal), the lack of return value detail is acceptable. Covers the basics for an overview tool.

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 has 0% description coverage. The description mentions 'head/tail samples' hinting at sample_lines, but does not explicitly explain file_path or sample_lines. It provides some context but lacks full parameter meaning beyond the schema.

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?

The description clearly states it provides a quick scan with metrics like size, line count, time range, level distribution, and samples. It positions itself as a first step, but does not explicitly differentiate from siblings like analyze_errors or search_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?

Explicitly says 'Use this as the first step when investigating a log file', providing clear context for when to invoke it. No mention of when not to use or alternatives, but the guidance is specific and actionable.

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

log_statsA

Compute log statistics: volume histogram over time, level breakdown, and top repeated message patterns.

Useful for spotting traffic spikes, error bursts, or noisy log sources.

ParametersJSON Schema
NameRequiredDescriptionDefault
file_pathYes
bucket_sizeNoauto
top_patternsNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A3.9/5.0
Behavior2/5

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

No annotations are provided, so the description carries full burden for behavioral disclosure. It explains the outputs but lacks details on side effects (e.g., file modification), performance implications, required permissions, or whether it is read-only. For a tool that processes a file, more transparency is needed.

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 two sentences long, with the first sentence front-loading the core purpose and outputs, and the second adding usage context. Every sentence is necessary and no repetition.

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

Completeness3/5

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

The tool has an output schema but the description does not mention return format; it lists outputs informally. It lacks details on file format expectations, size constraints, or behavior for missing files. Given the sibling context and parameter count, it is minimally adequate but has gaps.

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 description coverage is 0%, yet the description partially compensates by linking parameters to outputs: 'volume histogram over time' implies bucket_size controls time bins, and 'top repeated message patterns' relates to top_patterns. However, it does not explain file_path or bucket_size values thoroughly.

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 explicitly states what the tool does: 'Compute log statistics: volume histogram over time, level breakdown, and top repeated message patterns.' This clearly identifies the verb (compute) and resource (log statistics), with specific outputs that distinguish it from siblings like analyze_errors or search_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 provides a clear usage context: 'Useful for spotting traffic spikes, error bursts, or noisy log sources.' While it does not explicitly list when not to use or alternatives, the provided scenarios guide appropriate invocation.

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

search_logsB

Search log entries by regex pattern, log level, and/or time range.

Returns matching entries (up to max_results). Combine filters to narrow results.

ParametersJSON Schema
NameRequiredDescriptionDefault
file_pathYes
patternNo
log_levelNo
start_timeNo
end_timeNo
max_resultsNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

B3.2/5.0
Behavior2/5

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

No annotations provided. Description reveals it returns matching entries up to a limit, but omits behavioral details like ordering, performance characteristics, or side effects.

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, front-loaded with purpose, no wasted words.

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

Completeness2/5

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

With 6 parameters and no schema descriptions, the description is too brief. It lacks details on return format (despite output schema), ordering, and edge cases, making it incomplete given the tool's complexity and sibling context.

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?

The description partially compensates for 0% schema coverage by referencing pattern, log level, and time range filters. However, it omits file_path (required) and max_results, leaving some parameters unexplained.

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?

Clearly states it searches log entries by regex, log level, and time range (verb+resource+scope). However, it does not explicitly differentiate from sibling tools like analyze_errors or classify_lines.

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

Usage Guidelines3/5

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

Mentions combining filters and a max_results limit, but lacks explicit when-to-use guidance compared to alternatives and no prerequisites or exclusions.

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.

  1. 7 tool updatesv0.1.0
    • First observedanalyze_errors
    • First observedclassify_lines
    • First observedcompare_logs
    • First observedget_log_segment
    • First observedlog_overview
    • First observedlog_stats
    • First observedsearch_logs
Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.8/5.0

Scored across 7 tools

Disambiguation5/5

Each tool has a distinct purpose: error grouping, line classification, log comparison, segment extraction, overview, statistics, and search. No two tools overlap in functionality.

Naming Consistency4/5

Most tools follow a verb_noun pattern (analyze_errors, classify_lines, compare_logs, get_log_segment, search_logs), but log_overview and log_stats use a noun_verb structure, breaking the pattern slightly.

Tool Count5/5

Seven tools cover the core log analysis workflow (overview, search, stats, error analysis, classification, comparison, extraction) without being excessive or insufficient.

Completeness4/5

Covers essential log investigation tasks comprehensively, though missing advanced features like live tail or user-defined filters. No critical gaps for typical use.

Maintenance

ActivityInactive
ResponsivenessNo issues

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

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

Related MCP Connectors

Related MCP Servers

  • Log Analyzer MCP

    djm81
    F
    license
    B
    quality
    D
    maintenance
    A Python-based MCP server that enables AI-assisted log file analysis with features for filtering, parsing, and interpreting log outputs, plus executing and analyzing test runs with varying verbosity levels.
    12
    12
    -

  • Log Analyzer MCP Server

    suriya-ML
    A
    license
    Not graded
    quality
    D
    maintenance
    An MCP server for intelligent log analysis providing semantic search, error pattern clustering, and smart error detection. It enables users to process, vectorize, and query local logs to efficiently identify issues and generate AI-powered summaries.
    MIT

  • quickwit-mcp

    agarwalvivek29
    A
    license
    Not graded
    quality
    F
    maintenance
    A read-only MCP server that exposes Quickwit log search and aggregations to LLM clients, enabling natural language log investigation.
    Apache 2.0

  • Graylog MCP Server

    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.
    23
    27
    MIT