Which integrations are available for this server?

Analyzes logging quality in C++ code, detecting issues like print/cerr overuse, error swallowing, and provides improvement suggestions. Analyzes logging quality in JavaScript code, detecting issues like console.log overuse, sensitive data exposure, and provides improvement suggestions. Analyzes logging quality in Kotlin code, detecting issues like println overuse, error swallowing, and provides improvement suggestions. Analyzes logging quality in PHP code, detecting issues like echo/print overuse, error swallowing, and provides improvement suggestions. Analyzes logging quality in Python code, detecting issues like print overuse, error swallowing, and provides improvement suggestions. Analyzes logging quality in Ruby code, detecting issues like puts overuse, error swallowing, and provides improvement suggestions. Analyzes logging quality in Rust code, detecting issues like println! overuse, error swallowing, and provides improvement suggestions. Analyzes logging quality in Swift code, detecting issues like print overuse, error swallowing, and provides improvement suggestions. Analyzes logging quality in TypeScript code, detecting issues like console.log overuse, sensitive data exposure, and provides improvement suggestions.

How do I use Logging Advisor MCP?

1. Click on "Deploy Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Logging Advisor MCP Check my logging" 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.

Logging Advisor MCP

by g-hyeong

Overview Schema Source Related Servers Discussions Admin

TypeScript

Local

Logging Advisor MCP

"Just say 'check my logging' and let it handle everything automatically"

An intelligent MCP (Model Context Protocol) server that analyzes logging quality in your code and provides improvement suggestions using LLM-powered insights. Features natural language interaction and automated workflows.

Installation

npm install -g logging-advisor-mcp

Related MCP server: Log Analyzer MCP

MCP Client Setup

Claude Desktop

Add to your configuration file:

macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Windows: %APPDATA%\Claude\claude_desktop_config.json

{
  "mcpServers": {
    "logging-advisor": {
      "command": "npx",
      "args": ["logging-advisor-mcp"],
      "env": {}
    }
  }
}

Claude Code

claude mcp add logging-advisor -- npx -y logging-advisor-mcp

After configuration, restart your MCP client. The logging advisor tools will be available.

Natural Language Interface

Simply say:

"Check my logging"
"Is my logging code okay?"
"Too many console.log statements"
"Improve my error logging"
"Production deployment logging check"

The MCP automatically detects what you need and runs the appropriate workflow.

4-Step Automated Workflow

1. 🚀 `setup_analysis_session` - Smart Setup

Natural matching: Recognizes casual requests about logging
Auto-detection: Programming language, environment settings
Smart defaults: Production-ready configuration
Workflow guidance: Clear next steps

2. 📊 `analyze_logging` - Quality Analysis

Pattern detection: console.log/print overuse, error swallowing
Security scanning: Sensitive data exposure (passwords, tokens, PII)
Performance review: Blocking I/O, debug leaks in production
Multi-language: JavaScript, Python, Java, Go, C++, C#, Ruby

3. 🔧 `suggest_improvements` - ROI-Based Roadmap

Quick wins: Critical fixes (1-2 hours)
Line-by-line fixes: Exact code replacements
Implementation guide: Difficulty, time estimates, dependencies
Migration strategy: Gradual improvement avoiding big-bang changes

4. ✅ `validate_production_readiness` - Deployment Safety

Strict GO/NO-GO: Any critical issue blocks deployment
5-gate validation: Security, Performance, Observability, Operations, Compliance
Real impact focus: Actual service disruption prevention

Example Usage

Natural Workflow

You: "Check my logging - is this code production ready?"

[Paste your code]

Claude: [Automatically runs setup_analysis_session]
→ "I'll analyze your JavaScript code for production deployment..."
→ [Runs analyze_logging, suggest_improvements, validate_production_readiness]
→ "❌ NO-GO: Critical security issue detected - password exposed in logs"
→ [Provides exact line-by-line fixes]

Manual Tool Usage

Please analyze this code with setup_analysis_session:

console.log('User:', username, password);
try {
  loginUser();
} catch(e) {
  // empty catch
}

Features

🎯 Natural Language Interface

Conversational: "Check my logging" → automatic workflow
Smart matching: Recognizes various ways of requesting logging help
Zero configuration: Works with smart defaults

🔍 Comprehensive Analysis

Security scanning: Sensitive data exposure (passwords, tokens, PII)
Performance review: Blocking I/O, excessive debug logging
Observability check: Correlation IDs, error context preservation
Multi-language: JavaScript, Python, Java, Go, C++, C#, Ruby

🚀 Production-Ready Focus

Environment-aware: Different standards for dev vs production
Strict validation: GO/NO-GO deployment decisions
Real-world impact: Focus on actual operational issues
ROI-based improvements: Quick wins prioritized

Deployment Decision Matrix

Decision	Criteria	Action
✅ GO	No Critical issues, <20% High issues	Safe to deploy
⚠️ CONDITIONAL GO	No Critical, some High issues	Deploy with monitoring
❌ NO-GO	Any Critical issues present	Fix required before deployment

Critical Blockers

Sensitive data in logs (passwords, tokens, PII)
Synchronous I/O logging (performance risk)
Empty error handling (lost error context)
Production debug logging enabled

Language Support

Primary: JavaScript/TypeScript, Python, Java, Go
Extended: C++, C#, Ruby, PHP, Rust, Kotlin, Swift

Development

Local Development Setup

git clone https://github.com/g-hyeong/logging-advisor-mcp.git
cd logging-advisor-mcp
npm install
npm run build

Testing with MCP Inspector

npx @modelcontextprotocol/inspector dist/index.js
# Open http://localhost:5173 in your browser
# Test all 4 tools: setup_analysis_session, analyze_logging, suggest_improvements, validate_production_readiness

Development Setup for Various Clients

Claude Desktop (Development):

{
  "mcpServers": {
    "logging-advisor": {
      "command": "node",
      "args": ["/absolute/path/to/dist/index.js"]
    }
  }
}

Cursor IDE (Development):

{
  "mcp": {
    "servers": {
      "logging-advisor": {
        "command": "node",
        "args": ["/absolute/path/to/dist/index.js"]
      }
    }
  }
}

Claude Code (Development):

{
  "claude.mcpServers": {
    "logging-advisor": {
      "command": "node",
      "args": ["/absolute/path/to/dist/index.js"]
    }
  }
}

Examples

Poor Logging Code

console.log('Login:', username, password); // Exposes sensitive data
try {
  doSomething();
} catch (e) {
  // Empty catch - ignores errors
}

Expected Analysis:

Score: 20-30
Issues: Critical security vulnerability, ignored errors
Recommendations: Use structured logger, remove sensitive data

Good Logging Code

logger.info('Login attempt', { 
  username, 
  timestamp: Date.now() 
});
try {
  doSomething();
} catch (error) {
  logger.error('Operation failed', { 
    error: error.message, 
    stack: error.stack 
  });
}

Expected Analysis:

Score: 85-95
Issues: None or minor
Patterns: Structured logging, consistent approach

Architecture

LLM-First + User-Friendly Design

Natural language interface: Conversational interaction patterns
Automated workflows: 4-step process with smart defaults
Minimal implementation: Maximum delegation to LLM capabilities
Context preservation: Session-aware tool chaining

Scripts

npm run dev        # Development mode with auto-restart
npm run build      # TypeScript build
npm run typecheck  # Type checking only
npm start          # Production execution

License

Apache-2.0

Contributing

Issues and pull requests are welcome on GitHub.

Available Tools

4 tools

analyze_loggingA

Logging code quality analysis and issue diagnosis

When used: Automatically executed after setup_analysis_session or when direct logging analysis is needed

Analysis items:

Detect console.log/print overuse patterns
Sensitive information exposure risks (password, token, email, etc.)
Missing error handling and context loss
Performance blocking logging (synchronous I/O)
Lack of observability (correlation ID, tracing)
DEBUG logging inappropriate for production

Output: Provides professional logging analysis guidelines to LLMs for accurate quality assessment

Supported languages: JavaScript, TypeScript, Python, Java, Go, C++, C#, Ruby Environment: differentiated analysis for development, production

ParametersJSON Schema

Name	Required	Description	Default
`focus`	No	Analysis focus - all: comprehensive analysis, patterns: logging patterns, security: sensitive data exposure, errors: error handling, performance: performance impact	all
`language`	Yes	Programming language - provides language-specific analysis guidelines
`environment`	No	Target environment - production: strict standards, development: development convenience considered	production

TDQS

A3.9/5.0

Behavior3/5

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

No annotations are provided, so the description carries the full burden. It discloses that output is 'professional logging analysis guidelines to LLMs' rather than raw results, and describes supported languages/environments. However, it doesn't state whether it mutates anything, how long it takes, or anything about rate limits. Adequate but not rich.

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

Conciseness4/5

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

Front-loaded with purpose, then clearly sectioned (When used, Analysis items, Output, Supported languages, Environment). The bullet list is dense but each item earns its place. Slightly verbose for a tool with such a well-documented schema.

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 a 3-param analysis tool with 100% schema coverage and no output schema, the description supplies the missing behavioral context: what gets analyzed, what the output is, supported languages, and environment differentiation. It stops short of explaining the return structure, but for an LLM-guideline-producing tool that's minor.

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 coverage is 100% and all three parameters have enums with descriptions. The description's 'Analysis items' and 'Environment: differentiated analysis for development, production' loosely map to the focus and environment params, but it adds no syntax or format detail beyond the schema. Baseline 3 is appropriate.

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?

States a specific verb+resource: it analyzes logging code quality and diagnoses issues. The bulleted 'Analysis items' list makes the scope concrete and distinguishes it from siblings like validate_production_readiness (readiness checks) and suggest_improvements (fix suggestions). An agent can tell it produces analysis/guidelines, not edits or validation.

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

Usage Guidelines4/5

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

Explicitly states 'When used': automatically after setup_analysis_session, or when direct logging analysis is needed. This names the sibling and the trigger condition. It doesn't explain when NOT to use it or how it differs from suggest_improvements, but the routing context is clear.

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

setup_analysis_sessionB

Start code logging quality inspection and improvement

Use for requests like: "Check if logs are okay", "Improve logging", "Any issues with log code?", "Check logging before production deployment", "Too many console.log statements", "Is error logging working properly?", "Optimize logs"

Automatically handles:

Auto-detect logging patterns in code
Provide language-specific optimization suggestions (JavaScript, Python, Java, Go, etc.)
Validate production environment safety
Observability improvement guidance

3-step automated workflow: 1 Logging quality analysis → 2 Improvement roadmap generation → 3 Deployment safety validation

Settings (optional): environment, serviceCriticality, targetScore, maxChanges, focus Defaults: production environment, high criticality, 80-point target, 5 changes max, comprehensive analysis

ParametersJSON Schema

Name	Required	Description	Default
`focus`	No	Analysis focus area - all: comprehensive analysis, patterns: logging patterns, security: security, errors: error handling, performance: performance impact	all
`language`	No	Programming language (optional, will provide general guidelines if not specified)
`environment`	No	Target environment - production: strict standards, development: development convenience considered	production
`serviceCriticality`	No	Service criticality - low: internal tools, medium: general services, high: core services, critical: financial/healthcare	high

TDQS

B3.3/5.0

Behavior3/5

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

With no annotations, the description carries the full burden. It discloses the automated workflow, optional settings, and defaults, but does not clarify whether it modifies code, what the output looks like, or any permission/side-effect details. This is adequate but incomplete for a setup/orchestration tool.

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

Conciseness3/5

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

The description is front-loaded and organized with clear sections, but it is verbose with many example phrases and a settings/defaults section that is partly incorrect. It could be tightened while retaining the useful context.

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?

For a complex orchestrator tool with no annotations and no output schema, the description covers purpose and usage well but omits key context: how it relates to its sibling tools, what it returns, and whether it is a prerequisite for individual analysis steps.

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?

The schema has 100% description coverage, but the description's settings list is inaccurate: it includes targetScore and maxChanges (not in the schema) and omits the language parameter. This mismatch could mislead an agent into passing unsupported arguments.

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 states a clear verb (Start) and resource (code logging quality inspection and improvement), and outlines a 3-step workflow. It does not explicitly differentiate this orchestrator tool from its siblings (analyze_logging, suggest_improvements, validate_production_readiness), so it stops short of a 5.

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?

It provides many example user requests that clearly indicate when to use the tool, and lists optional settings with defaults. However, it does not state when not to use it or how it relates to the sibling tools, which prevents a 5.

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

suggest_improvementsA

Generate logging improvement roadmap and specific modification suggestions

When used: Automatically executed after analyze_logging completion or when direct improvement suggestions are needed

What it provides:

Immediately applicable Quick Wins (1-2 hours)
Phased migration plan (prevents Big Bang approach)
Line-by-line precise modification code
ROI-based prioritization (cost vs. benefit)
Implementation difficulty and estimated time required
Required library/configuration guidance

Improvement patterns:

console.log → structured logger (winston, pino)
Error ignoring → complete context preservation
Synchronous logging → asynchronous performance optimization
Sensitive data exposure → complete removal/masking
Untraceable → correlation ID addition

Operational safety: Preserve existing logic, incremental application, rollback plan

ParametersJSON Schema

Name	Required	Description	Default
`focus`	No	Improvement focus area	all
`language`	Yes	Programming language - provides language-specific improvement patterns
`complexity`	No	Improvement complexity - quick: 1-2 hours, standard: half day, comprehensive: full migration	standard
`currentIssues`	No	Current logging issues identified (optional) - e.g., ["console.log overuse", "missing error context", "sensitive data exposure"]

TDQS

A3.5/5.0

Behavior3/5

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

With no annotations, the description carries the full behavioral burden. It does describe operational safety ('Preserve existing logic, incremental application, rollback plan'), which is useful context about the generated output. However, it doesn't disclose whether this is a read-only operation, whether it modifies files, or its execution model. The safety notes are about the suggestions, not the tool's own behavior.

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

Conciseness3/5

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

The description is heavily formatted with headers and bullet lists, making it longer than necessary. The front-loaded purpose is clear, but the extensive enumeration of improvement patterns and benefits could be distilled. It's structured but somewhat bloated.

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 no output schema, the description needs to compensate. It describes what the tool provides but omits critical behavioral details like whether it's read-only, how it interacts with the analysis session, or error handling. It covers the 'what' well but leaves gaps in the 'how'.

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 description coverage is 100%, so the baseline is 3. The description mentions 'language-specific improvement patterns' and the focus/complexity concepts loosely map to the schema, but adds no syntax or format details beyond what the structured schema already provides.

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 states a specific verb+resource ('Generate logging improvement roadmap and specific modification suggestions'), which is clear enough. However, it doesn't differentiate itself from the sibling 'analyze_logging' beyond saying it's 'automatically executed after analyze_logging completion'. A stronger description would directly contrast the two tools' scopes.

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 context for when to use: 'Automatically executed after analyze_logging completion or when direct improvement suggestions are needed.' It names the prerequisite sibling tool, which helps routing. It lacks explicit when-not-to-use guidance or a direct alternative, but the trigger conditions are adequately specified.

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

validate_production_readinessA

Final logging safety validation before production deployment

When used: Automatically executed after suggest_improvements completion or when final pre-deployment inspection is needed

Strict GO/NO-GO determination:

Immediate NO-GO if even one Critical issue exists
Comprehensive evaluation of security, performance, operational stability
Focus on actual service failure possibilities

5-stage safety validation: 1 Security Gate: Complete sensitive data blocking (password, token, PII) 2 Performance Gate: Prevent service performance blocking 3 Observability Gate: Ensure incident response capability 4 Operational Gate: Monitoring system integration 5 Compliance Gate: Regulatory compliance (GDPR, audit)

Deployment decision:

GO: Safe to deploy
CONDITIONAL GO: Deploy with caution due to limited risks
NO-GO: Deployment prohibited, fixes required

Critical Blockers: console.log, sensitive data exposure, synchronous I/O logging, error ignoring

ParametersJSON Schema

Name	Required	Description	Default
`language`	Yes	Programming language - provides language-specific validation checklist
`environment`	No	Target deployment environment - staging: relatively lenient, production: strict standards	production
`knownIssues`	No	Known issues from previous analysis (optional) - helps focus validation on specific areas
`serviceCriticality`	No	Service criticality - low: internal tools, medium: general services, high: core services, critical: financial/healthcare	high

TDQS

A4.1/5.0

Behavior4/5

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

With no annotations, the description carries the full burden and does so well: it discloses the GO/CONDITIONAL GO/NO-GO decision logic, the 5-stage gate structure, and concrete critical blockers (console.log, sensitive data, sync I/O). It omits read-only/auth/rate-limit characteristics, keeping it from a 5.

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?

Front-loaded with the core purpose, then organized into labeled sections that are scannable. It is long, but since there is no output schema, the decision-outcome taxonomy earns its space; a few stage descriptions are borderline restatements.

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

Completeness4/5

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

Given no output schema, the description appropriately explains the possible verdicts and the gating criteria an agent needs to interpret results. It stops short of describing return payload shape or where findings surface, a minor gap.

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 description coverage is 100%, and the description does not add meaning beyond the schema's field descriptions (language, environment, knownIssues, serviceCriticality). Baseline 3 applies when the schema already documents all 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?

States a specific verb (validate) and resource (logging safety for production readiness) in the opening line. It also distinguishes itself from sibling suggest_improvements by declaring that it runs after that tool's completion.

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

Usage Guidelines4/5

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

Explicitly states when it runs ('after suggest_improvements completion') and the triggering condition ('final pre-deployment inspection needed'). It lacks an explicit when-not or an alternative for the pre-final case, so it falls just short of 5.

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

Tool Schema Changelog

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

4 tool updatesv1.1.1Sep 13, 2026
- First observedanalyze_logging
- First observedsetup_analysis_session
- First observedsuggest_improvements
- First observedvalidate_production_readiness

Deploy Server

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

TDQS

A3.8/5.0

Scored 2026-09-13 11:15 across 4 tools

Disambiguation4/5

Each tool targets a distinct phase of the logging improvement workflow, and descriptions clarify boundaries. However, analyze_logging and suggest_improvements have some overlap in addressing logging issues, though the intended separation is clear.

Naming Consistency5/5

All tool names follow a consistent snake_case verb_noun pattern: setup_analysis_session, analyze_logging, suggest_improvements, validate_production_readiness. This predictable pattern aids discoverability.

Tool Count5/5

Four tools are perfectly scoped for a guided logging advisor workflow. Each tool covers one stage of the process (setup, analyze, suggest, validate), and no extraneous tools are included.

Completeness4/5

The tool set covers the entire logging improvement lifecycle from analysis to production validation. However, it lacks a tool for direct code modification or applying fixes, but this may be intentional to keep the advisor focused on guidance rather than execution.

Maintenance

ActivityInactive

ResponsivenessNo issues

Resources

Need Help?

Related Servers

Related MCP Connectors

MCP FortressOAuth
io.github.mcp-fortress
Security scanner for MCP servers. Detect vulnerabilities, prompt injection, and tool poisoning.
Security Testing & QA Tools Penetration Testing
2
mcp AOAuth
io.scorecard
MCP server providing access to the Scorecard API to evaluate and optimize LLM systems.
RAG Systems Monitoring Testing & QA Tools
3
looptool
dev.looptool
An MCP server that automatically collects feedback on your MCP server.
Monitoring Developer Tools
2
llm-output-quality-monitor B
io.github.lazymac2x
Cloudflare Workers MCP server: llm-output-quality-monitor
Monitoring Observability
52

Related MCP Servers

Log Analyzer MCP
Monitoring Developer Tools
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.
Updated a year ago (2025-06-08 20:21 UTC)
12
12
-
Log Analyzer MCP
Monitoring Observability Developer Tools
Fato07
A
license
A
quality
C
maintenance
An MCP server for AI-powered log analysis that enables parsing, searching, and debugging across nine log formats directly within Claude. It features automated error extraction, sensitive data scanning, and streaming support for large log files.
Updated 8 months ago (2026-01-16 16:39 UTC)
14
28 PyPI
5
MIT
Log Analyzer MCP Server
RAG Systems Vector Databases Monitoring
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.
Updated 9 months ago (2025-12-19 16:37 UTC)
MIT
log-mcp
Monitoring Observability
ascii766164696D
A
license
A
quality
D
maintenance
MCP server for log file analysis. Gives LLMs the ability to efficiently analyze large log files without loading them into context.
Updated 7 months ago (2026-02-28 20:40 UTC)
7
100
MIT

Logging Advisor MCP

Installation

MCP Client Setup

Claude Desktop

Claude Code

Natural Language Interface

4-Step Automated Workflow

1. 🚀 setup_analysis_session - Smart Setup

2. 📊 analyze_logging - Quality Analysis

3. 🔧 suggest_improvements - ROI-Based Roadmap

4. ✅ validate_production_readiness - Deployment Safety

Example Usage

Natural Workflow

Manual Tool Usage

Features

🎯 Natural Language Interface

🔍 Comprehensive Analysis

🚀 Production-Ready Focus

Deployment Decision Matrix

Critical Blockers

Language Support

Development

Local Development Setup

Testing with MCP Inspector

Development Setup for Various Clients

Examples

Poor Logging Code

Good Logging Code

Architecture

LLM-First + User-Friendly Design

Scripts

License

Contributing

Available Tools

Tool Schema Changelog

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

1. 🚀 `setup_analysis_session` - Smart Setup

2. 📊 `analyze_logging` - Quality Analysis

3. 🔧 `suggest_improvements` - ROI-Based Roadmap

4. ✅ `validate_production_readiness` - Deployment Safety