Integrates with a local Ollama instance to provide semantic log analysis and root cause diagnosis, including checking Ollama connection and model status, with automatic fallback to a built-in rule engine when Ollama is unavailable.
Click on "Deploy 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., "@LogAnalyze-MCP 分析一下 D:/logs/app.log 最近的错误，告诉我根因和修复方案"
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.
基于 MCP（Model Context Protocol） 的本地日志智能分析服务，让 Cursor / Claude Code / Trae 等 AI Agent 直接读取、筛选、统计并自动诊断你的日志文件。
排查线上问题时，开发者通常要反复执行「打开日志 → 找 ERROR → 搜关键词 → 看堆栈 → 百度报错」。 LogAnalyze-MCP 把这套流程封装成标准 MCP 工具，AI Agent 用一句自然语言就能自主完成排查，并给出根因与修复建议。
🔒 纯本地运行：日志文件不离开本机，基于 stdio 通信
🧠 双引擎分析：本地 Ollama 大模型语义分析 + 内置规则引擎兜底（未装 Ollama 也能用）
📦 零配置上手：9 个工具覆盖日志排查 80% 日常场景
🪶 轻量无依赖：仅需 Python，流式读取 GB 级大日志不爆内存
🗜️ 压缩日志直读：透明支持 .gz（如 app.log.gz）与 .zip（支持多成员），无需先手动解压
Related MCP server: Local Lens
工具 | 作用 |
| 列出目录下日志文件（含 |
| 读取日志末尾 N 行（恒定内存，适合超大文件） |
| 读取日志开头 N 行（查看启动信息） |
| 关键词/正则搜索，带回溯上下文 |
| 按 FATAL/ERROR/WARN 等级别筛选并计数 |
| 统计报告：行数、时间范围、级别分布、高频错误 Top5 |
| 智能诊断：抽取错误 → 根因分析 → 修复建议 |
| 直接分析粘贴的报错/堆栈片段 |
| 检查 Ollama 连接与模型状态 |
Python 3.10+
（可选）Ollama：启用大模型语义分析；不安装则使用规则引擎
git clone https://github.com/<your-name>/log-analyze-mcp.git
cd log-analyze-mcp
# 建议使用虚拟环境
python -m venv .venv
# Windows
.venv\Scripts\activate
# macOS / Linux
source .venv/bin/activate
pip install -r requirements.txt# 安装 Ollama 后拉取模型（CPU 可选 3b/1.5b，追求效果选 7b）
ollama pull qwen2.5:7b如需自定义，复制 .env.example 为 .env，修改 OLLAMA_BASE_URL、OLLAMA_MODEL。
# 单元测试（不依赖 MCP/Ollama）
python tests/test_tools.py
# 端到端验证：启动 MCP server → 握手 → 真实调用工具
python examples/test_client.pySettings → Features → MCP → Add new MCP server，填入（路径替换为本机实际路径）：
{
"mcpServers": {
"log-analyze": {
"command": "python",
"args": ["-u", "src/server.py"],
"cwd": "C:/path/to/log-analyze-mcp",
"env": {
"OLLAMA_MODEL": "qwen2.5:7b"
}
}
}
}完整模板见 examples/cursor-config.json。
复制 examples/claude-code-mcp.json 中的 mcpServers 段到项目 .mcp.json 或 claude_desktop_config.json。
接入后，直接在 Agent 对话框用自然语言：
「帮我看看 D:/logs 目录下有哪些日志文件」
「分析一下 app.log 最近的错误，告诉我根因和修复方案」
「搜索日志里所有 timeout 相关记录，带 3 行上下文」
「统计这个日志里 ERROR 和 WARN 各有多少条」
Agent 会自动编排工具调用链：
list_log_files → get_log_stats → filter_log_by_level → analyze_log，最终输出结构化诊断报告。
┌──────────────┐ stdio / JSON-RPC ┌──────────────────────┐ HTTP ┌──────────┐
│ AI Agent │ ◀──────────────────▶ │ LogAnalyze-MCP │ ◀─────────────▶ │ Ollama │
│ Cursor / CC │ tools/call │ (FastMCP Server) │ (本地，可选) │ 本地大模型 │
└──────────────┘ │ 9 个日志分析工具 │ └──────────┘
│ 规则引擎（兜底） │
└──────────────────────┘
│ 只读
▼
本地日志文件（不上传）AI Agent 作为 MCP Host，通过 stdio 启动本服务并完成能力协商；
Agent 自主规划排查步骤，按需调用工具；
工具流式读取本地日志，返回结构化文本；
诊断类工具调用本地 Ollama 生成根因分析；Ollama 不可用时自动降级为规则引擎。
log-analyze-mcp/
├── src/
│ ├── server.py # MCP 服务入口（FastMCP，9 个工具）
│ ├── config.py # 配置加载（环境变量 > config.json > 默认值）
│ ├── tools/
│ │ ├── log_reader.py # 日志读取/搜索/筛选/统计
│ │ └── log_analyzer.py # 智能诊断编排
│ └── llm/
│ └── ollama_client.py # Ollama 客户端 + 规则引擎
├── examples/
│ ├── sample.log # 演示用样例日志
│ ├── test_client.py # 端到端验证脚本
│ ├── cursor-config.json
│ └── claude-code-mcp.json
├── tests/test_tools.py
├── requirements.txt
└── config.json本工具仅做本地只读日志分析，不会修改、删除、上传任何文件；
请仅在你有权限访问的机器与日志上使用；
规则引擎与大模型的分析结论仅供参考，生产环境请结合监控与代码复核。
支持 gzip/zip 压缩日志直接读取（v1.1.1）
支持日志多格式自动解析（JSON Lines、自定义正则、logback 模板）
错误时间线视图与跨文件关联分析
支持 OpenAI 兼容接口（如内网 vLLM 部署）
可选 Web 看板（只读）
对用户直接粘贴的一段报错/堆栈文本进行智能根因分析（无需日志文件）。
Args: error_text: 报错信息或异常堆栈原文。
| Name | Required | Description | Default |
|---|---|---|---|
| error_text | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It says the analysis is 'intelligent' but never discloses that this is an LLM-backed call, nor any latency, cost, input-size limit, or failure behavior — relevant given the sibling check_llm_status. Only the 'no log file needed' note adds any behavioral context.
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 short, front-loaded sentences: the capability first, then the parameter. Nothing is padded, though the docstring-style 'Args:' block is slightly formulaic for a single obvious parameter.
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?
An output schema exists, so return values need not be explained. For a single-parameter analysis tool this is close to adequate, but with zero annotations the description leaves undisclosed how the analysis is performed and any limits on the pasted text.
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 0%, so the description must carry the parameter meaning, and it does: error_text is the raw error message or exception stack text. It compensates for the empty schema description, though it adds no constraints such as size limits or accepted formats.
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 names a specific verb (智能根因分析 / intelligent root-cause analysis) and a specific resource (a piece of error/stack text pasted directly by the user). The parenthetical '无需日志文件' implicitly separates it from the log-file siblings such as analyze_log and read_log_tail, so an agent can route correctly without opening either schema.
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 gives a clear condition for use: the user has pasted raw error text and no log file is involved. This contrasts with the file-oriented siblings (list_log_files, analyze_log), though it never names an alternative tool or states an explicit exclusion, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
智能分析日志：自动抽取错误，给出根因、证据与修复建议。
优先使用本地 Ollama 大模型；未安装或未启动时自动降级为内置规则引擎。
Args: file_path: 日志文件绝对路径。 max_lines: 送入分析的最大日志行数，0 表示使用配置默认值（400）。
| Name | Required | Description | Default |
|---|---|---|---|
| file_path | Yes | ||
| max_lines | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and does disclose a key non-obvious behavior: it prioritizes local Ollama LLM and automatically falls back to a built-in rule engine if unavailable. It does not explicitly state read-only side effects or file-access prerequisites, but it goes well beyond the minimum.
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?
The description is front-loaded with purpose and fallback behavior, then lists only the two arguments. Every sentence adds unique value with no redundant or filler content.
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?
An output schema exists, so return values need not be explained. The description covers parameters and the LLM fallback behavior, but it omits guidance on when to choose this tool over the many sibling log-analysis tools.
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 0%, so the description fully compensates by documenting both parameters. It specifies that file_path must be an absolute path and explains max_lines semantics including that 0 uses the configured default of 400.
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 states a specific verb and resource ('智能分析日志') plus its high-level outputs (自动抽取错误、根因、证据、修复建议). It does not explicitly differentiate itself from sibling tools like analyze_error_text or get_log_stats, so it stops short of the top score.
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?
No guidance is given on when to use this tool versus siblings such as analyze_error_text, search_log_keyword, or read_log_tail. The fallback behavior is described, but that is behavioral transparency, not usage routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
检查本地 Ollama 服务与模型是否可用；不可用时会提示安装命令与降级状态。
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden, and it does disclose useful failure behavior: an install command is surfaced and a degraded state is reported when the service is unavailable. However, it says nothing about whether the check is read-only/side-effect free, how long it may block, or whether results are cached/refreshed.
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?
A single compact sentence that front-loads the check and follows with the failure behavior. No filler, no redundancy, no restating of the tool name.
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?
An output schema exists, so return structure need not be explained, and with zero parameters the definition is nearly complete. The only meaningful gap is the absence of any cue about when this diagnostic is warranted relative to the analysis siblings.
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 tool takes zero parameters, so there is nothing for the description to disambiguate; baseline 4 applies. No parameter-related information is needed or missing.
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?
Names a specific verb and resource: checking availability of the local Ollama service and its models. It is clearly distinguishable from the log-centric siblings (list_log_files, read_log_tail, analyze_log), though it never explicitly says so.
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?
No when-to-use guidance, no prerequisites, and no mention of the sibling tools or of when an agent should prefer this check over proceeding directly. The most an agent can infer is that it is a diagnostic step, which is implied rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
按日志级别筛选记录并统计条数；筛选某级别时会同时包含更严重级别。
Args: file_path: 日志文件绝对路径。 level: 目标级别，可选 FATAL/ERROR/WARN/INFO/DEBUG/TRACE，默认 ERROR。
| Name | Required | Description | Default |
|---|---|---|---|
| level | No | ERROR | |
| file_path | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and it does disclose a genuinely non-obvious behavioral rule: filtering a level also includes more severe levels (filtering WARN returns ERROR/FATAL too). It also tells the agent that counts are produced, not just matching records. It omits permission/read-only expectations and any size or performance caveats.
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?
Front-loaded with the two key facts (filter by level, count results, hierarchy rule) in one dense sentence, followed by a compact Args block. Every line earns its place, though the arg block partially repeats the schema.
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?
An output schema exists, so return structure need not be explained, and both parameters plus the critical level-hierarchy rule are covered. What is missing for a two-param selector in a crowded sibling set is any routing guidance relative to the other six log tools.
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 0% and the schema has no enums, so the description must compensate — and it does fully. It documents file_path as an absolute path, lists the exact allowed level values (FATAL/ERROR/WARN/INFO/DEBUG/TRACE), and restates the ERROR default, leaving nothing ambiguous.
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?
States a specific verb+resource — filtering log records by level and counting them — which is concrete and easy to distinguish from read-only siblings like read_log_tail or get_log_stats. It does not, however, name or contrast with any sibling to help the agent route between them.
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?
Usage is implied by the purpose and by the level parameter semantics, but the description never states when to prefer this over search_log_keyword, get_log_stats, or analyze_log. No prerequisites or exclusions are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
生成日志统计报告：文件大小、总行数、时间范围、级别分布、高频错误 Top5。
Args: file_path: 日志文件绝对路径。
| Name | Required | Description | Default |
|---|---|---|---|
| file_path | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It reveals the output content but says nothing about whether the operation is read-only, how it behaves on huge files, whether the file must exist, or any performance/rate considerations.
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?
Purpose is front-loaded in a single dense sentence listing the report sections, followed by a compact Args block. No filler, though it is not maximally tight.
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?
An output schema exists, so return values needn't be re-explained, and the single-parameter surface is simple. However, the absence of any annotation or usage routing leaves the agent without guidance on when this tool is preferred over analyze_log.
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 0%, so the description must compensate. It documents the sole parameter as the absolute path of the log file (日志文件绝对路径), adding the 'absolute path' requirement that the schema (type string, title 'File Path') does not convey.
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 names a specific verb+resource (生成日志统计报告 / generate log statistics report) and enumerates the exact report contents: file size, total lines, time range, level distribution, and Top 5 frequent errors. This clearly differentiates it from read_log_tail/head, search_log_keyword, and filter_log_by_level, though it never explicitly contrasts with the potentially overlapping analyze_log.
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 only states what the tool produces; it gives no guidance on when to choose it over analyze_log, analyze_error_text, or the other seven siblings. No prerequisites or exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
列出指定目录下的所有日志文件（.log/.txt/.out/.err/.trace），含大小与修改时间。
Args: dir_path: 日志目录的绝对路径。 recursive: 是否递归扫描子目录，默认 True。
| Name | Required | Description | Default |
|---|---|---|---|
| dir_path | Yes | ||
| recursive | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden, and it does disclose the extension filter and that size/mtime are included. However, it doesn't state that this is a read-only operation, how results are ordered, or how missing/unreadable directories are handled, leaving gaps for a tool with zero annotation coverage.
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?
The core behavior and extension scope are front-loaded in the first sentence, with parameters following in a compact Args block. Because schema coverage is 0%, the Args list earns its place rather than being pure duplication, and there is little wasted text.
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?
An output schema exists, so return-value explanation is unnecessary, and both parameters plus the purpose are documented. Minor gaps remain around error/empty-directory behavior and sorting, but nothing essential to calling the tool correctly is missing.
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 0%, so the description must compensate, and it does: dir_path is explained as the absolute path of the log directory, and recursive is explained as whether to scan subdirectories with its default (True). Both parameters gain meaning beyond the bare schema types.
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?
Clear specific verb (list) and resource (log files in a directory), and it even narrows scope to specific extensions (.log/.txt/.out/.err/.trace) and returned metadata (size, mtime). It is readily distinguishable from siblings like read_log_tail/search_log_keyword, though it never explicitly contrasts itself with them.
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?
Usage is only implied: an agent can infer this is the enumeration step before reading or analyzing logs. There is no explicit when-to-use statement, no condition selecting it over alternatives, and no prerequisites mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
读取日志文件开头指定行数（适合查看启动参数与启动阶段日志）。
Args: file_path: 日志文件绝对路径。 lines: 要读取的行数，默认 100，最大 5000。
| Name | Required | Description | Default |
|---|---|---|---|
| lines | No | ||
| file_path | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the full behavioral burden. It does disclose a meaningful constraint absent from the schema (max 5000 lines, default 100), but says nothing about missing-file behavior, encoding, truncation warnings, or output shape. Adequate, 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
One purpose sentence plus a compact Args block; front-loaded purpose, no filler, and the constraint values are attached directly to their parameters.
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?
An output schema exists, so return values need not be described, and the tool is a simple two-parameter read. Purpose, bounds, and both parameters are covered; only error-handling expectations are absent.
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 0%, so the description must compensate, and it does: file_path is defined as an absolute path, lines gets a default and a hard ceiling of 5000. The only gap is that no format/encoding expectation is stated for the path or content.
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?
States a specific verb+resource (读取日志文件开头指定行数) and adds scope (startup parameters/startup phase logs), which implicitly separates it from the head/tail family. It never names the obvious sibling read_log_tail, so the differentiation is left partly to inference from '开头'.
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?
Gives a clear use case — viewing startup parameters and startup-phase logs — which tells the agent when this tool is the right pick over a general read or search. No explicit exclusions or named alternatives are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
读取日志文件末尾指定行数（适合查看最新报错，对超大文件同样高效）。
Args: file_path: 日志文件绝对路径。 lines: 要读取的行数，默认 100，最大 5000。
| Name | Required | Description | Default |
|---|---|---|---|
| lines | No | ||
| file_path | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full behavioral burden. It usefully discloses tail semantics and large-file efficiency (implying it does not load the whole file), which is real value. It says nothing about failure modes (missing file, permission denied) or what happens when 'lines' exceeds 5000.
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?
One front-loaded summary sentence followed by a lean Args block; every line carries information. The parenthetical efficiency note could arguably be its own concern, but nothing is wasted.
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?
An output schema exists, so return values need not be explained, and both parameters are covered in the description. What remains missing is error/edge-case behavior, but for a 2-param read tool with an output schema this is close to 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 0%, so the description must compensate, and it does: file_path is documented as an absolute path and lines as default 100 / max 5000 — the 5000 cap exists nowhere in the schema. Minor gap: no statement of behavior on out-of-range values.
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?
States a specific verb+resource ('读取日志文件末尾指定行数') plus a scope note (efficient on very large files), so the action is unambiguous. It does not explicitly distinguish itself from the natural sibling read_log_head, though '末尾' implies the contrast.
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?
'适合查看最新报错' gives a concrete situation for use and '对超大文件同样高效' hints at a second, but there is no when-not guidance and the sibling read_log_head is never mentioned as the alternative for head-of-file inspection. Usage is implied rather than routed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
在日志中按关键词或正则表达式搜索，返回命中行及其上下文。
Args: file_path: 日志文件绝对路径。 keyword: 关键词；regex 为 True 时视为正则表达式。 regex: 是否按正则匹配，默认 False（普通子串匹配）。 context: 每个命中前后展示的上下文行数，默认 2。 max_results: 最多返回的命中组数，默认 50。
| Name | Required | Description | Default |
|---|---|---|---|
| regex | No | ||
| context | No | ||
| keyword | Yes | ||
| file_path | Yes | ||
| max_results | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
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 implies a read-only search and describes the hit-plus-context output, but says nothing about permissions, behavior on missing/unreadable files, regex flavor, or how large files are handled.
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?
The summary sentence is front-loaded and the per-argument notes are terse; nothing is repeated verbatim from the schema in a wasteful way. Slightly list-heavy but appropriate for a five-parameter tool.
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 an output schema present, return values need not be explained, and the parameters are covered. However, with zero annotations and eight siblings, the definition lacks the usage context and safety profile an agent would need to route and invoke it confidently.
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 0%, so the description must compensate, and it largely does: it documents all five parameters, clarifying that file_path is an absolute path, that keyword is interpreted as a regex when regex=True, and the meaning and defaults of context and max_results. It loses a point only for not specifying regex syntax details.
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 first sentence gives a specific verb and resource ('在日志中按关键词或正则表达式搜索') plus the return shape ('返回命中行及其上下文'), which is concrete enough to distinguish it from read_log_tail or filter_log_by_level. It stops short of explicitly naming which sibling to prefer, so it is clear but not sibling-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?
There is no statement of when to use this over filter_log_by_level, analyze_error_text, or the read_log_head/tail pair, and no prerequisites (file must exist, encoding, size limits) are given. Usage is only implied by the verb 'search'.
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.
v1.1.1analyze_error_textanalyze_logcheck_llm_statusfilter_log_by_levelget_log_statslist_log_filesread_log_headread_log_tailsearch_log_keywordScored across 9 tools
Each tool targets a distinct operation: listing, head/tail reading, keyword search, level filtering, stats, and AI analysis. The main potential overlap is between search_log_keyword and filter_log_by_level, but their descriptions clearly distinguish regex/keyword matching from level-based severity filtering. Boundaries are clear enough that misselection is unlikely.
All tools use snake_case with a consistent verb_noun pattern (list_log_files, read_log_tail, search_log_keyword, filter_log_by_level, get_log_stats, analyze_log, check_llm_status). The convention is predictable and readable throughout.
Nine tools is well-scoped for a log analysis server, with each tool earning its place across the read/search/filter/analyze lifecycle. No redundancy or bloat.
Coverage is strong: discovery, head/tail reads, keyword and level filtering, stats, AI-driven root-cause analysis for both files and pasted text, plus an LLM status check. Minor gaps exist (e.g., no cross-file aggregation or export/report-writing operation), but core log analysis workflows are fully supported.
Query application logs, traces, and metrics from your AI coding assistant via Foam's MCP server.
MCP server for your apps' tools and custom tools, plus hosted AI agents and approval-gated workflows
Persistent memory, knowledge graph, task management and more for AI agents via MCP.
OCR, transcription, file extraction, and image generation for AI agents via MCP.
