This MCP server enables AI assistants to intelligently inspect and analyze runtime log files for debugging and troubleshooting by providing direct access to log files from configured directories.
Core Tools:
list_log_files: Scan all configured directories to see available log files
get_log_content: Retrieve complete content of specific log files (suitable for smaller files)
read_log_paginated: Read large log files in token-based chunks with line numbers and file change detection to respect AI context limits
search_log_file: Search using regex patterns with configurable context lines, case sensitivity, and pagination options
Key Features:
Multiple directory support: Monitor logs from several directories simultaneously (system logs, application logs, test logs, etc.)
File change detection: Track file modifications during pagination to detect when logs are actively being written
Automatic AI guidance: Built-in runtime-logs prompt informs AI about log inspection capabilities and enables proactive log checking when users report errors
Flexible configuration: Specify log directories via command-line arguments, environment variables, or default location ($XDG_RUNTIME_DIR/log)
Flexible file referencing: Specify logs by filename (searches all directories) or full absolute path
Use Cases: Development debugging, service monitoring, multi-project debugging, and AI-assisted learning from runtime behavior. Includes best practices and examples for configuring applications (Node.js, Python, Java, Rust, Go) and IDEs to write logs to monitored directories.
Click on "Install 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., "@Log MCP Server check the latest error logs from my web app"
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.
A Model Context Protocol (MCP) server that enables AI assistants to intelligently inspect and analyze runtime log files for debugging and troubleshooting.
This MCP server bridges the gap between your application logs and AI assistants like Claude. When you encounter errors or unexpected behavior in your code, the AI can automatically inspect your runtime logs to diagnose the problem - no more copying and pasting log files back and forth!
The workflow:
Your applications write logs to a configured directory (e.g., $XDG_RUNTIME_DIR/log or custom paths)
This MCP server gives your AI assistant read access to those logs
When you report a problem, the AI proactively checks the logs to find the root cause
Get faster, more accurate debugging assistance based on actual runtime data
Related MCP server: Local Logs MCP Server
Development debugging: AI analyzes application logs when tests fail or errors occur
Service monitoring: Quickly diagnose issues with background services and daemons
Multi-project debugging: Monitor logs from multiple applications simultaneously
Learning & training: Understand what your code is doing at runtime by having AI explain the logs
Multiple Directory Support: Monitor logs from multiple directories simultaneously
Automatic AI Guidance: When activated, the AI is informed about log inspection capabilities and will proactively check logs when users report errors
list_log_files: Lists all log files across all configured directories
get_log_content: Reads and returns the content of a specific log file
read_log_paginated: Read large files in chunks with line numbers
search_log_file: Regex search with context lines and pagination
runtime-logs prompt: Provides context to the AI about when and how to use log inspection
git clone <repository-url>
cd log-mcp
pip install -e .pip install log-inspector-mcpAdd to your Claude Desktop config (~/.config/claude/claude_desktop_config.json):
Default directory ($XDG_RUNTIME_DIR/log):
{
"mcpServers": {
"log-inspector": {
"command": "log-mcp"
}
}
}Single custom directory:
{
"mcpServers": {
"log-inspector": {
"command": "log-mcp",
"args": ["--log-dir", "/var/log"]
}
}
}Multiple directories:
{
"mcpServers": {
"log-inspector": {
"command": "log-mcp",
"args": [
"--log-dir", "/var/log",
"--log-dir", "/tmp/logs",
"--log-dir", "$XDG_RUNTIME_DIR/log"
]
}
}
}Using environment variable (colon-separated):
{
"mcpServers": {
"log-inspector": {
"command": "log-mcp",
"env": {
"LOG_MCP_DIR": "/var/log:/tmp/logs:$XDG_RUNTIME_DIR/log"
}
}
}
}Or using uvx (recommended):
{
"mcpServers": {
"log-inspector": {
"command": "uvx",
"args": ["log-mcp", "--log-dir", "/var/log"]
}
}
}# Use default directory
log-mcp
# Use single custom directory
log-mcp --log-dir /var/log
# Use multiple directories
log-mcp --log-dir /var/log --log-dir /tmp/logs
# Use environment variable (colon-separated)
LOG_MCP_DIR=/var/log:/tmp/logs log-mcp
# See all options
log-mcp --helpThe server determines log directories in this order (highest priority first):
--log-dir command-line arguments (can be specified multiple times)
LOG_MCP_DIR environment variable (colon-separated paths, like PATH)
$XDG_RUNTIME_DIR/log (default)
When multiple directories are configured:
list_log_files scans all directories and returns all found files
Other tools accept either:
Just the filename (searches all directories for the file)
Full absolute path (must be within one of the allowed directories)
When the MCP server connects to Claude, it automatically informs the AI that:
Runtime logs are available for inspection
These logs should be checked whenever users report errors or problems
The logs contain valuable diagnostic information for troubleshooting
The AI will proactively use the log inspection tools when appropriate.
Lists all log files found in $XDG_RUNTIME_DIR/log.
Parameters: None
Returns: List of full paths to all log files found
When to use: First step when investigating any error or problem
Reads and returns the complete content of a specific log file.
Parameters:
filename (string, required): Name of the log file to read
Returns: The full content of the specified log file
When to use: For small log files; for large files, use read_log_paginated instead
Reads a specific portion of a log file with token-based pagination to respect AI context limits. Tracks file modifications to detect changes during pagination.
Parameters:
filename (string, required): Name of the log file to read
start_line (integer, optional): Starting line number (1-based, default: 1)
max_tokens (integer, optional): Maximum tokens to return (default: 4000, max: 100000). Uses ~4 chars per token estimation.
expected_size (integer, optional): Expected file size in bytes (from previous call). Warns if file changed.
expected_mtime (number, optional): Expected modification timestamp (from previous call). Warns if file was modified.
num_lines (integer, optional): DEPRECATED - Maximum number of lines (max: 1000). If specified, overrides max_tokens for backward compatibility.
Returns: Lines with line numbers, file metadata (size, mtime), and warnings if file changed during pagination
When to use: For large log files where you need to read specific sections without exceeding context limits
Examples:
Read from start: start_line=1
Read 10000 tokens from line 500: start_line=500, max_tokens=10000
Continue with change detection: start_line=1234, expected_size=5678910, expected_mtime=1234567890.123
File Modification Detection:
Each response includes file_size and file_mtime
Use these values in the next call as expected_size and expected_mtime
If the file changed, you'll get a warning: "⚠️ FILE SIZE CHANGED" or "⚠️ FILE MODIFIED"
This helps detect when log files are actively being written to
Why token-based? Log lines vary drastically in length. Token-based pagination ensures consistent AI context usage regardless of line length.
Searches a log file using regex patterns and returns matching lines with surrounding context.
Parameters:
filename (string, required): Name of the log file to search
pattern (string, required): Regex pattern to search for
context_lines (integer, optional): Lines to show before/after each match (default: 2, max: 10)
context_before (integer, optional): Lines to show before each match (max: 10). Overrides context_lines for before-context.
context_after (integer, optional): Lines to show after each match (max: 10). Overrides context_lines for after-context.
case_sensitive (boolean, optional): Case-sensitive search (default: false)
max_matches (integer, optional): Maximum matches to return (default: 50, max: 500)
skip_matches (integer, optional): Number of matches to skip for pagination (default: 0)
Returns: Matching lines with context, marked with >>> for the match line
When to use: Searching for specific errors, patterns, or events in log files
Examples:
Search for all "ERROR" entries with 3 lines of context: context_lines=3
Show 5 lines before and 2 after each match: context_before=5, context_after=2
Show only lines after the match: context_before=0, context_after=5
A prompt that explains to the AI how and when to use log inspection capabilities. This is automatically available when the server connects.
Configure your application to log to $XDG_RUNTIME_DIR/log/myapp.log
Add log-mcp to Claude Desktop config
Run your application - it writes logs as it runs
Ask Claude for help: "My application is crashing when I click the submit button"
Claude automatically:
Calls list_log_files to see available logs
Calls search_log_file to find error messages
Analyzes the error context
Provides a solution based on the actual error
No more manual log copy-pasting! The AI has direct, intelligent access to your runtime diagnostics.
For the AI to help debug your applications, they need to write logs to a directory the MCP server monitors. Here are common configuration patterns:
$XDG_RUNTIME_DIR/logOn most Linux systems, $XDG_RUNTIME_DIR is /run/user/<UID> (e.g., /run/user/1000). Create the log directory:
mkdir -p $XDG_RUNTIME_DIR/logUsing Winston:
const winston = require('winston');
const logger = winston.createLogger({
transports: [
new winston.transports.File({
filename: `${process.env.XDG_RUNTIME_DIR}/log/myapp.log`
})
]
});Using Pino:
const pino = require('pino');
const logger = pino(
pino.destination(`${process.env.XDG_RUNTIME_DIR}/log/myapp.log`)
);Using logging module:
import logging
import os
log_dir = os.path.join(os.environ.get('XDG_RUNTIME_DIR', '/tmp'), 'log')
os.makedirs(log_dir, exist_ok=True)
logging.basicConfig(
filename=os.path.join(log_dir, 'myapp.log'),
level=logging.DEBUG,
format='%(asctime)s - %(name)s - %(levelname)s - %(message)s'
)application.properties:
logging.file.path=${XDG_RUNTIME_DIR}/log
logging.file.name=${XDG_RUNTIME_DIR}/log/myapp.logUsing env_logger:
use std::env;
use std::fs::File;
fn setup_logging() {
let runtime_dir = env::var("XDG_RUNTIME_DIR").unwrap_or("/tmp".to_string());
let log_file = format!("{}/log/myapp.log", runtime_dir);
// Configure your logger to write to log_file
}package main
import (
"log"
"os"
"path/filepath"
)
func main() {
runtimeDir := os.Getenv("XDG_RUNTIME_DIR")
if runtimeDir == "" {
runtimeDir = "/tmp"
}
logPath := filepath.Join(runtimeDir, "log", "myapp.log")
f, err := os.OpenFile(logPath, os.O_APPEND|os.O_CREATE|os.O_WRONLY, 0644)
if err != nil {
log.Fatal(err)
}
log.SetOutput(f)
}Create .vscode/tasks.json:
{
"version": "2.0.0",
"tasks": [
{
"label": "Run with logging",
"type": "shell",
"command": "node app.js > $XDG_RUNTIME_DIR/log/myapp.log 2>&1"
}
]
}Edit Run Configuration
Add VM options or Environment Variables:
Set log file path to $XDG_RUNTIME_DIR/log/myapp.log
Or modify logging configuration file (logback.xml, log4j.properties, etc.)
You can monitor logs from different locations simultaneously:
# System logs + application logs + test logs
log-mcp --log-dir /var/log \
--log-dir $XDG_RUNTIME_DIR/log \
--log-dir $HOME/projects/myapp/logsOr use the environment variable:
export LOG_MCP_DIR="/var/log:$XDG_RUNTIME_DIR/log:$HOME/projects/myapp/logs"Python 3.10+
MCP SDK
$XDG_RUNTIME_DIR environment variable (or specify custom directories)
Quickly finds error lines in a log file by matching common error patterns (ERROR, Exception, FATAL, Failed, Traceback, panic, etc.). Ideal for quick diagnostics.
| Name | Required | Description | Default |
|---|---|---|---|
| filename | Yes | Name of the log file to search | |
| max_tokens | No | Maximum tokens to return (default: 4000, max: 100000). Uses ~4 chars per token estimation. | |
| context_lines | No | Number of lines to show before and after each error (default: 2, max: 10) | |
| include_warnings | No | Also include warning-level messages (default: false) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It lists error patterns searched but does not disclose return format, performance guarantees, or whether the tool modifies files. Adequate but not detailed.
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 front-load purpose and ideal use. No filler, every word adds value.
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?
Without output schema, description does not explain what the tool returns (e.g., lines with context, format). Among 7 sibling tools, no differentiation guidance beyond the listed patterns. Adequate for simple use but incomplete for an agent needing return structure.
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?
Input schema has 100% coverage with descriptions for all 4 parameters. The tool description does not add extra meaning to parameters; it lists error patterns used internally, which is not about parameter values. Baseline 3 is appropriate.
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 finds error lines in a log file by matching specific patterns (ERROR, Exception, etc.), distinguishing it from sibling tools like search_log_file which may support generic queries.
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 says 'Ideal for quick diagnostics,' implying a use case, but does not specify when to use other tools or exclude scenarios. No guidance on when not to use or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns the content of a specific log file from $XDG_RUNTIME_DIR/log. Use this to inspect runtime logs when debugging errors or investigating problems. For large files, use read_log_paginated instead.
| Name | Required | Description | Default |
|---|---|---|---|
| filename | Yes | Name of the log file to read | |
| max_tokens | No | Maximum tokens to return (default: 4000, max: 100000). Uses ~4 chars per token estimation. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and description only mentions returning content. Lacks disclosure of error handling, permissions, or what happens if file is missing. Missing behavioral details expected for a read operation without annotations.
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?
Three concise sentences: core function, usage context, alternative. No unnecessary words.
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?
Simple tool with 2 params and no output schema. Description covers directory, purpose, and large file alternative. Lacks error condition details but otherwise complete for its complexity.
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 100%, so baseline is 3. Description adds minor value by clarifying token estimation ('~4 chars per token') and default/max values already in 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?
Description clearly states 'Returns the content of a specific log file from $XDG_RUNTIME_DIR/log' and positions it for debugging. Distinguishes from sibling read_log_paginated.
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?
Explicitly states when to use ('when debugging errors or investigating problems') and provides an alternative for large files with 'use read_log_paginated instead'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Reads the beginning of a log file (like Unix 'head' command). Uses token-based pagination to respect AI context limits.
| Name | Required | Description | Default |
|---|---|---|---|
| lines | No | Number of lines to read from the beginning. If not specified, uses token-based limit. | |
| filename | Yes | Name of the log file to read | |
| max_tokens | No | Maximum tokens to return (default: 4000, max: 100000). Uses ~4 chars per token estimation. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses token-based pagination behavioral trait, but without annotations, missing details on destructiveness (assumed read-only), error handling, auth requirements, or output format.
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 concise sentences, front-loaded with essential information, no 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?
Adequate for a simple read tool but lacks output format description and clear differentiation from read_log_paginated, which also uses pagination.
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 100%; description adds no new meaning beyond the parameter descriptions already in 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?
Clearly states it reads the beginning of a log file, analogous to Unix 'head'. Differentiates from siblings like tail_log and read_log_paginated by specifying start-of-file orientation.
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?
Implies usage via Unix 'head' analogy and mentions token-based pagination for AI limits, but no explicit guidance on when to use this vs siblings like read_log_paginated or tail_log.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lists all log files in $XDG_RUNTIME_DIR/log. Use this FIRST when user says 'inspect', 'inspector', 'logs', or reports errors/problems. This is the entry point for log inspection - discover available logs before using other tools.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It minimally describes behavior (listing files) but doesn't disclose potential performance or side effects. For a zero-parameter read-only tool, this is acceptable but not exemplary.
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 that are clear and front-loaded, but the second sentence partly restates the entry point concept. Minor redundancy but still efficient.
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 zero parameters, no output schema, and a clear purpose, the description fully informs an agent about what the tool does and when to use it.
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?
No parameters exist, and schema coverage is 100%. The description adds no additional semantic information about the output format or contents of the list.
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 verb 'lists', the resource 'log files', and the location. It distinguishes itself from siblings by positioning itself as the entry point for log inspection.
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?
Explicitly specifies when to use this tool first, listing relevant user intents and framing it as the discovery step before other log tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Reads a paginated portion of a log file. Useful for large log files. Uses token-based pagination to respect AI context limits. Tracks file modifications to detect changes between pagination calls.
| Name | Required | Description | Default |
|---|---|---|---|
| filename | Yes | Name of the log file to read | |
| num_lines | No | DEPRECATED: Use max_tokens instead. Maximum number of lines (max: 1000). If specified, overrides max_tokens. | |
| max_tokens | No | Maximum tokens to return (default: 4000, max: 100000). Uses ~4 chars per token estimation. | |
| start_line | No | Starting line number (1-based, default: 1) | |
| expected_size | No | Expected file size in bytes (from previous call). If file size changed, returns a warning. | |
| expected_mtime | No | Expected modification time timestamp (from previous call). If file was modified, returns a warning. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries the burden. It discloses key behaviors: token-based pagination, change tracking via expected_size and expected_mtime. This goes beyond simple read into operational details. No contradiction with missing annotations. However, it does not mention error states or side effects, slightly lowering the score.
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?
Three sentences, each dense with information. No fluff. Front-loaded with the primary action. 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?
With no output schema, the description should explain return values. It implies change tracking results but not explicitly. The parameter richness (6 params) is well-covered by schema, so overall adequate but lacks output format clarity. Still, it's reasonably complete for an agent.
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 100%, so baseline is 3. The description adds no per-parameter semantics beyond what the schema already provides. It mentions overall behaviors (pagination, change tracking) but not parameter-specific 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 it reads a paginated portion of a log file, which distinguishes it from siblings like head_log, tail_log, and read_log_range. The mention of 'paginated' and 'large log files' makes its purpose specific and differentiated.
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 explicitly says 'Useful for large log files' and mentions 'token-based pagination to respect AI context limits', providing clear guidance on when to use. However, it does not explicitly state when not to use or name alternatives, though the sibling context implies when other tools might be preferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Reads a specific range of lines from a log file. Uses token-based pagination to respect AI context limits.
| Name | Required | Description | Default |
|---|---|---|---|
| end_line | No | Ending line number (1-based, inclusive). If not specified, reads to end of file or token limit. | |
| filename | Yes | Name of the log file to read | |
| max_tokens | No | Maximum tokens to return (default: 4000, max: 100000). Uses ~4 chars per token estimation. | |
| start_line | No | Starting line number (1-based, inclusive) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses token-based pagination, default and max tokens, character-per-token estimation, and behavior when end_line is unspecified. This adds meaningful context beyond basic read functionality.
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, each adding essential information. The first sentence states the primary purpose, the second explains key behavioral constraint. No wasted words.
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?
With 4 fully documented parameters and no output schema, the description covers the main behavioral aspects. It lacks error handling details or output format, but for a simple read tool with sibling context, it is reasonably complete.
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 100%, so parameters are already well-documented. The description adds minor value by contextualizing max_tokens and pagination, but does not significantly enhance understanding of individual parameters beyond 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 'Reads a specific range of lines from a log file,' specifying the verb and resource. It differentiates from siblings like head_log or tail_log by focusing on a range, and mentions token-based pagination, which adds context.
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 implies usage for reading line ranges with pagination but does not explicitly advise when to use this tool versus alternatives like read_log_paginated or head_log. No exclusions or prerequisites are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Searches a log file using regex pattern and returns matching lines with surrounding context. Supports token-based pagination to respect AI context limits.
| Name | Required | Description | Default |
|---|---|---|---|
| pattern | Yes | Regex pattern to search for | |
| filename | Yes | Name of the log file to search | |
| max_tokens | No | Maximum tokens to return (default: 4000, max: 100000). Uses ~4 chars per token estimation. When specified, overrides max_matches. | |
| max_matches | No | DEPRECATED: Use max_tokens instead. Maximum number of matches to return (max: 500). If specified, overrides max_tokens. | |
| skip_matches | No | Number of matches to skip (for pagination, default: 0) | |
| context_after | No | Number of lines to show after each match (max: 10). Overrides context_lines for after-context. | |
| context_lines | No | Number of lines to show before and after each match (default: 2, max: 10). Overridden by context_before/context_after if specified. | |
| case_sensitive | No | Whether the search should be case-sensitive (default: false) | |
| context_before | No | Number of lines to show before each match (max: 10). Overrides context_lines for before-context. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden but only states basic behavior (search, return matches with context, pagination). It does not disclose side effects (e.g., file access permissions), performance, or error handling for missing files or invalid patterns.
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, both front-loaded with core purpose and a key feature. No wasted words.
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?
Despite 9 parameters and no output schema, the description provides a decent high-level view but omits parameter interdependencies (e.g., max_tokens vs max_matches deprecation). It is adequate but incomplete for a complex 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 coverage is 100% with detailed parameter descriptions. The description adds minimal extra meaning beyond the schema, just mentioning token-based pagination. Baseline 3 is appropriate.
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 searches a log file with regex and returns matching lines with context, which is specific. However, it does not explicitly differentiate from siblings like 'find_errors' or 'read_log_paginated', though regex search is implied as distinct.
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 mentions token-based pagination for AI context limits, giving a usage hint, but lacks explicit when-to-use or when-not-to-use guidance compared to siblings. No alternatives are named.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Reads the end of a log file (like Unix 'tail' command). Uses token-based pagination to respect AI context limits. Ideal for checking recent log entries.
| Name | Required | Description | Default |
|---|---|---|---|
| lines | No | Number of lines to read from the end. If not specified, uses token-based limit. | |
| filename | Yes | Name of the log file to read | |
| max_tokens | No | Maximum tokens to return (default: 4000, max: 100000). Uses ~4 chars per token estimation. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses token-based pagination to respect AI context limits, which is critical for correct invocation. However, it fails to explain the interaction between the 'lines' and 'max_tokens' parameters, and no annotations are provided to indicate the operation is read-only.
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 concise sentences that front-load the purpose and key behavior. Every sentence carries distinct information with no 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?
The description covers core purpose and an important behavior (token pagination). However, it omits error handling, return format, and the exact interplay between 'lines' and 'max_tokens', leaving some gaps for an agent.
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 full coverage for all three parameters. The description adds value by explaining the token-pagination context for max_tokens and likening the tool to the Unix 'tail' command, which aids understanding of the lines parameter.
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 reads the end of a log file using a Unix 'tail' analogy, and distinguishes itself from siblings like head_log and read_log_paginated by explicitly mentioning token-based pagination for AI context limits.
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 phrase 'Ideal for checking recent log entries' implies when to use, but there is no explicit guidance on when not to use or how to choose among siblings like search_log_file or find_errors.
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. Dates show when Glama detected each change.
v0.2.1find_errorsget_log_contenthead_loglist_log_filesread_log_paginatedread_log_rangesearch_log_filetail_logv0.4.2find_errorsget_log_contenthead_loglist_log_filesread_log_paginatedread_log_rangesearch_log_filetail_logv0.4.1get_log_contentlist_log_filesread_log_paginatedsearch_log_filev1.0.0get_log_contentlist_log_filesread_log_paginatedsearch_log_fileEach tool has a clearly distinct purpose with no ambiguity: list_log_files identifies available logs, get_log_content retrieves full log content, read_log_paginated handles large files with pagination, and search_log_file performs pattern-based searches. The descriptions explicitly differentiate them, such as warning about using read_log_paginated for large files instead of get_log_content.
All tools follow a consistent verb_noun pattern (e.g., get_log_content, list_log_files) with clear, descriptive names that use snake_case uniformly. There are no deviations in naming conventions, making the set predictable and easy to understand.
With 4 tools, this server is well-scoped for its log management purpose, covering essential operations like listing, reading, paginating, and searching logs. Each tool earns its place without redundancy, and the count is appropriate for the domain, avoiding both thinness and bloat.
The tool surface is nearly complete for log inspection, covering key workflows from discovery to detailed analysis. A minor gap exists in write operations (e.g., creating or clearing logs), but this is reasonable for a read-focused debugging server, and agents can work around it as the core functionality is well-covered.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Read-only access to Auralogs production logs: search logs, inspect errors, review AI analyses.
Query application logs, traces, and metrics from your AI coding assistant via Foam's MCP server.
Open-source agent that observes and fixes your application. Query logs, traces, metrics, incidents.
Structured knowledge base for AI agent solutions. Search, explore, and retrieve build logs.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/thhart/log-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
