Logging Advisor MCP
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| 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:
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 |
| 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:
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 |
| 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:
Improvement patterns:
Operational safety: Preserve existing logic, incremental application, rollback plan |
| 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:
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:
Critical Blockers: console.log, sensitive data exposure, synchronous I/O logging, error ignoring |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 4 tools
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.
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.
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.
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.