Skip to main content
Glama

MCP 服务器:分析和调试 MCP 日志

🎯 概述

MCP 日志读取器是一款专用的 MCP 服务器,可帮助您分析和调试模型上下文协议 (MCP) 日志。它允许 Claude 直接访问日志文件,从而轻松排除 MCP 集成故障,并了解 Claude 如何与您的工具交互。

  • 多平台支持:适用于 macOS、Windows 和 Linux,具有平台特定的日志路径

  • 智能过滤:使用不区分大小写的文本搜索查找特定的日志条目

  • 分页浏览:高效浏览大量日志集合

  • 大小管理:使用智能截断处理大型日志文件

  • 无缝 Claude 集成:直接与 Claude Desktop 协同工作

Related MCP server: Log Analyzer MCP

🚀 快速入门

直接从 GitHub 安装:

# Clone the repository
git clone https://github.com/klara-research/MCP-Analyzer.git
cd MCP-Analyzer

# Install dependencies
npm i

构建并运行:

# Compile TypeScript
npx tsc

🔌 连接到 Claude

将服务器添加到您的 Claude Desktop 配置:

{
  "mcpServers": {
    "log-reader": {
      "command": "node",
      "args": [
        "/absolute/path/MCP-Analyzer/build"
      ]
    }
  }
}

然后重新启动 Claude Desktop。

📋 可用参数

日志阅读器支持以下参数:

范围

描述

默认

lines

从每个日志文件读取的行数

100

filter

用于过滤日志条目的文本(不区分大小写)

“”

customPath

自定义日志目录路径

特定于操作系统

fileLimit

每页读取的最大文件数

5

page

页码

1

💡 使用示例

要求 Claude 使用日志阅读器工具:

Can you check my MCP logs for any connection errors in the last day?

或者使用特定参数:

Can you look through MCP logs with filter="error" and lines=50 to find initialization issues?

⚙️ 工作原理

  1. 服务器自动检测您的操作系统并找到适当的日志目录

  2. 它定位所有 MCP 日志文件并按修改时间排序(最新的在前)

  3. 根据分页设置检索所请求的日志文件页面

  4. 文件处理时有大小限制,以防止响应过多

  5. 过滤后的内容以结构化格式返回,并带有分页详细信息

📄 许可证

MIT 许可证

Available Tools

1 tool
read_mcp_logsC

Read MCP logs from the standard location

ParametersJSON Schema
NameRequiredDescriptionDefault
customPathNoOptional custom path to log directory (default is system-specific)
fileLimitNoMaximum number of files to read per page (default: 5)
filterNoOptional text to filter log entries by (case-insensitive)
linesNoNumber of lines to read from the end of each log file (default: 100)
pageNoPage number for pagination (default: 1)

TDQS

C2.9/5.0
Behavior2/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions reading logs but fails to describe key behaviors like whether this is a safe read operation, what the output format looks like, or any limitations (e.g., file size constraints, error handling). This leaves significant gaps for a tool with multiple parameters.

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 a single, efficient sentence that directly states the tool's purpose without unnecessary words. It is appropriately sized and front-loaded, making it easy for an agent to parse quickly.

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 the tool has 5 parameters, no annotations, and no output schema, the description is incomplete. It does not address what the tool returns, how results are structured, or behavioral aspects like pagination details or error conditions, which are crucial for effective use.

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 schema description coverage is 100%, meaning all parameters are documented in the input schema. The description does not add any additional meaning or context beyond what the schema provides, such as explaining interactions between parameters or typical use cases. This meets the baseline for high schema coverage.

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 the action ('Read') and resource ('MCP logs from the standard location'), providing a specific verb+resource combination. However, with no sibling tools mentioned, it cannot demonstrate differentiation from alternatives, so it falls short of a perfect score.

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 offers no guidance on when to use this tool versus alternatives, prerequisites, or exclusions. It simply states what the tool does without context for its application, leaving the agent to infer usage scenarios.

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. 1 tool updatev1.0.0
    • First observedread_mcp_logs

TDQS

B3.1/5.0

Scored across 1 tool

Disambiguation5/5

With only one tool, there is no possibility of ambiguity or overlap between tools, making disambiguation perfect. The tool's purpose is clearly defined as reading MCP logs from a standard location, leaving no room for confusion with other tools.

Naming Consistency5/5

The single tool name 'read_mcp_logs' follows a clear verb_noun pattern, which is inherently consistent as there are no other tools to compare it against. This naming convention is straightforward and predictable for any potential future tools.

Tool Count2/5

A single tool is too few for a server named 'MCP Log Reader', as it suggests a limited scope that may not cover common log-related operations like filtering, searching, or managing logs. This minimal count feels thin and inadequate for the apparent domain of log reading.

Completeness2/5

The tool surface is severely incomplete for log reading; it only provides a basic read function without essential operations such as filtering by date, searching for specific entries, or handling different log levels. This gap will likely cause agent failures when more complex log interactions are needed.

Maintenance

ActivityInactive
ResponsivenessNo issues

Related MCP Connectors

Related MCP Servers

  • F
    license
    Not graded
    quality
    D
    maintenance
    A customizable Model Context Protocol server built with mcp-framework that enables Claude to access external tools and capabilities through a standardized interface.
    38 npm
    -
  • 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.
    14
    5
    MIT
  • A
    license
    Not graded
    quality
    B
    maintenance
    An MCP server that connects Claude (or any MCP compatible client) to your existing log infrastructure. Query, summarize, and trace logs in plain English across GCP Cloud Logging, AWS CloudWatch, Azure Log Analytics, Grafana Loki, and Elasticsearch without writing filter expressions or leaving your editor.
    204 npm
    4
    MIT
  • 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.
    7
    101
    MIT