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., "@Drain3 MCP Server Match this log: 'User 789 failed login from 10.0.0.1' and show parameters."
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.
基于 Drain3 的 Python MCP Server，把流式日志模板挖掘、只读匹配、参数提取和模型持久化封装成标准的 Model Context Protocol 工具。
逐条或批量训练日志模板
在不修改模型的前提下匹配新日志
提取 IP、数字、UUID、URL、十六进制值及 Drain3 通配参数
查询、排序和分页浏览已学习的模板
原子化文件快照，服务重启后自动恢复
同时支持 stdio、Streamable HTTP 和旧版 SSE 传输
返回结构化 MCP 输出，便于 Agent 稳定消费
Related MCP server: log-mcp
工具 | 用途 | 是否修改模型 |
| 学习一条日志并返回模板、簇和参数 | 是 |
| 按顺序批量学习日志 | 是 |
| 匹配一条日志，不创建新模板 | 否 |
| 批量只读匹配 | 否 |
| 查询已学习模板，支持排序和分页 | 否 |
| 按指定模板提取动态参数 | 否 |
| 查看模板数、消息数和有效配置 | 否 |
| 立即将完整模型状态写入快照 | 写快照 |
服务还公开以下 MCP Resources：
drain3://stats
drain3://templates
drain3://templates/{cluster_id}
需要 Python 3.10 或更高版本。
python -m venv .venv
# Linux / macOS
source .venv/bin/activate
# Windows PowerShell
.venv\Scripts\Activate.ps1
pip install -e .
drain3-mcp-server默认启动 stdio 传输，适合 Codex、Claude Desktop 等 MCP Host。也可以启动 Streamable HTTP：
drain3-mcp-server --transport streamable-http --host 127.0.0.1 --port 8000MCP 端点是 http://127.0.0.1:8000/mcp。
仓库开发模式：
{
"mcpServers": {
"drain3": {
"command": "D:/code/Drain3MCPServer/.venv/Scripts/python.exe",
"args": ["-m", "drain3_mcp_server"],
"env": {
"DRAIN3_MCP_STATE_PATH": "D:/data/drain3/state.bin"
}
}
}
}安装为命令后，可将 command 改成 drain3-mcp-server，并移除 args。
环境变量 | 默认值 | 说明 |
| 包内 | 自定义 Drain3 INI 配置路径 |
|
| 模型快照路径；设为 |
|
| 单次批量调用允许的最大日志条数 |
默认配置会掩码 IP、数字、UUID、URL 和十六进制值。生产环境通常应通过 DRAIN3_MCP_CONFIG_PATH 提供针对业务日志设计的 masking 规则。完整的 Drain3 参数定义请参考 Drain3 配置说明。
先训练两条相似日志：
{
"log_messages": [
"User 123 logged in from 10.0.0.1",
"User 456 logged in from 10.0.0.2"
]
}train_logs 会学习到类似下面的模板：
User <NUM> logged in from <IP>之后使用 match_log 可以对新日志做只读推理，并取得 NUM、IP 对应的参数值。
docker build -t drain3-mcp-server .
docker run --rm -p 8000:8000 -v drain3-data:/data drain3-mcp-server容器默认监听 0.0.0.0:8000，模型写入 /data/drain3_state.bin。
pip install -e ".[dev]"
pytest
ruff check .核心代码位于：
src/drain3_mcp_server/service.py：线程安全的 Drain3 服务层
src/drain3_mcp_server/server.py：MCP 工具、资源与启动入口
src/drain3_mcp_server/default_drain3.ini：默认模板挖掘配置
训练调用会沿用 Drain3 自身的快照策略；如需确保最新的簇计数立即落盘，请在训练批次结束后调用 save_state。
HTTP 模式下，单进程内的调用共享同一个 Drain3 模型，并通过可重入锁串行化访问。
若部署多个副本，每个副本应使用独立状态文件，或扩展为 Redis/Kafka 等共享持久化方案；本项目当前默认实现面向单实例。
HTTP 传输本身未配置身份认证。默认只监听回环地址；对外暴露时应放在带认证和 TLS 的网关之后。
Drain3 使用 jsonpickle 恢复快照，因此状态文件必须来自可信位置，不要加载第三方提供的快照。
Extract variable values from a log line using a Drain3 template.
| Name | Required | Description | Default |
|---|---|---|---|
| log_message | Yes | ||
| log_template | Yes | ||
| exact_matching | No |
| Name | Required | Description |
|---|---|---|
| matched | Yes | |
| template | Yes | |
| parameters | No | |
| log_message | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the operation read-only and idempotent, and the description's word 'Extract' is consistent with that. The description adds the Drain3 template detail, but it does not disclose behavior around exact_matching, non-matching logs, or how template variables map to extracted values.
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 one concise, front-loaded sentence with no filler. The action and mechanism are stated immediately, and every word contributes meaning.
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?
Annotations and an output schema reduce the burden of explaining safety and return values. However, the description omits exact_matching behavior and gives no guidance for choosing this tool over the match_log siblings, leaving a few meaningful gaps for a minimally complete definition.
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, but it only loosely maps to log_message and log_template. It does not explain exact_matching semantics or clarify how the Drain3 template placeholders correspond to the extracted variables.
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 action ('Extract variable values') and the resource ('a log line') with a clear method ('Drain3 template'). It does not explicitly distinguish itself from siblings like match_log or match_logs, but the extraction purpose is clear enough to imply that distinction.
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 this tool is for extracting variable values from logs, but it gives no explicit guidance about when to use it instead of the sibling tools. It does not state any exclusions or alternatives, leaving routing mostly to inference from the tool name and description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get aggregate model statistics and effective Drain3 settings.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| depth | Yes | |
| engine | Yes | |
| state_path | Yes | |
| max_children | Yes | |
| max_clusters | Yes | |
| cluster_count | Yes | |
| total_messages | Yes | |
| persistence_enabled | Yes | |
| similarity_threshold | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only, idempotent, non-destructive behavior, so the description does not need to restate those. It adds useful context by clarifying that the tool returns aggregate model statistics and the effective Drain3 settings rather than raw data or state changes, which is valuable beyond the annotation flags.
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 a single, front-loaded sentence with no redundant wording. Every word earns its place by identifying both the action and the exact content returned.
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?
For a parameterless, read-only stats tool with a rich set of annotations and an output schema, this description is fully sufficient. No prerequisites, side effects, or usage caveats are 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?
The tool takes zero parameters, so parameter documentation is not needed. The description confirms the operation is a parameterless retrieval, and the output schema covers the specific returned fields.
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 uses the specific verb 'Get' and names an explicit resource: aggregate model statistics and effective Drain3 settings. This clearly identifies what the tool does and differentiates it from sibling tools like train_logs, match_logs, and save_state, which involve different operations.
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 this tool is for retrieving read-only statistics and settings, but it gives no explicit guidance on when to choose it over alternatives. There are no stated exclusions or condition-based routing to sibling tools, so the usage context is only inferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List learned log templates with sorting and pagination.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| offset | No | ||
| sort_by | No | cluster_id | |
| descending | No |
| Name | Required | Description |
|---|---|---|
| limit | Yes | |
| total | Yes | |
| offset | Yes | |
| templates | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds that the operation supports sorting and pagination, which are behavioral traits, but does not disclose anything beyond the schema parameters. No contradiction with 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?
The description is a single concise sentence that front-loads the verb and resource and includes the key capabilities. No filler or redundant information, 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.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present and annotations covering safety, the description is largely complete: it names the resource, the operation, and the distinguishing capabilities. It could add context about when 'learned' templates are available, but this is not essential for invoking the tool correctly.
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, but it only provides the high-level phrase 'sorting and pagination.' It does not explain the semantics of limit, offset, sort_by, or descending beyond what their names imply, nor the meanings of enum values like cluster_id and cluster_size.
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 uses a specific verb 'List' and identifies the resource 'learned log templates,' with added scope on sorting and pagination. It clearly communicates the tool's purpose, though it does not explicitly distinguish from sibling tools like get_stats or match_logs by name.
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—call this tool when you need to retrieve learned log templates—and notes the sorting and pagination capabilities. However, it provides no explicit conditions, alternatives, or exclusions, leaving the agent to infer when this tool is preferred over siblings like get_stats.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Match one log line against learned clusters without changing the model.
| Name | Required | Description | Default |
|---|---|---|---|
| log_message | Yes | ||
| extract_parameters | No | ||
| full_search_strategy | No | fallback |
| Name | Required | Description |
|---|---|---|
| matched | Yes | |
| template | No | |
| cluster_id | No | |
| parameters | No | |
| change_type | No | |
| log_message | Yes | |
| cluster_size | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description reinforces this with 'without changing the model' and adds the context that matching happens against learned clusters. However, it does not disclose behavior such as what happens when no cluster matches or how optional parameters affect execution.
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 a single, front-loaded sentence with no filler. It efficiently conveys the core operation and side-effect guarantee, though it could have used the available space to clarify key 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?
With three parameters, one required, and zero schema descriptions, the description is too sparse. It does not explain the optional parameters or their enum values, nor the expected behavior on unmatched logs. The existence of an output schema helps, but parameter and edge-case context remain 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 bears the burden of explaining parameters. It only hints at log_message via 'one log line'. The purpose and effect of extract_parameters and full_search_strategy are not described, leaving an agent without enough information to choose correct 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?
The description states the specific verb 'match', the object 'one log line', and the target 'learned clusters', and emphasizes the non-mutating nature with 'without changing the model'. This clearly differentiates it from siblings like train_log (which trains) and match_logs (which suggests batch matching).
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 gives no explicit guidance on when to use this tool versus alternatives. It implies single-log inference via 'one log line' and 'without changing the model', but does not state conditions, exclusions, or mention match_logs as a batch alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Match a batch of log lines without changing the learned model.
| Name | Required | Description | Default |
|---|---|---|---|
| log_messages | Yes | ||
| extract_parameters | No | ||
| full_search_strategy | No | fallback |
| Name | Required | Description |
|---|---|---|
| mode | Yes | |
| total | Yes | |
| changed | Yes | |
| matched | Yes | |
| results | Yes | |
| unmatched | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior. The description adds a specific guarantee that the learned model is not changed, which is useful but not deeply rich. It does not mention matching strategy, output details, or error behavior, though annotations cover the safety profile.
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 concise sentence that leads with the core action and immediately states the key constraint. There is no filler, and every word contributes to the tool's purpose.
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 is too sparse for a tool with three parameters and an enum. While annotations and output schema cover safety and return shape, the semantics of extract_parameters and full_search_strategy are missing, making correct invocation uncertain. The tool name and siblings hint at the domain, but the description alone does not fully enable reliable use.
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 for missing parameter meaning. It only suggests that log_messages holds a batch of log lines, but extract_parameters and full_search_strategy are entirely unexplained. The enum values for full_search_strategy have no semantic guidance, leaving the agent to guess.
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: 'Match a batch of log lines.' The additional phrase 'without changing the learned model' clearly distinguishes it from training-oriented siblings like train_log/train_logs and from the singular match_log. An agent can understand both what it does and its scope.
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 provides clear context for when to use the tool: when matching multiple log lines and when model mutation is undesired. It does not explicitly name alternatives or exclusions, but the batch wording and the no-model-change constraint strongly imply the distinction from match_log and train_logs.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Write an immediate snapshot of the learned model to configured persistence.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| saved | Yes | |
| state_path | Yes | |
| cluster_count | Yes | |
| total_messages | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only, destructive, and idempotent hints, so the bar is lower. The description adds meaningful context by specifying that the operation writes an 'immediate snapshot' and where it goes ('configured persistence'), clarifying synchronous behavior and the persistence target beyond what annotations provide.
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, efficient sentence that front-loads the action ('Write') and avoids any filler. Every word contributes to identifying what the tool does and where the output goes.
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, an output schema, and annotations covering idempotency and destructiveness, the description provides enough context for an agent to correctly invoke save_state. No critical usage information appears 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?
The tool has zero parameters and the schema coverage is 100%, so there is no parameter documentation burden. The description adds semantic clarity about what is being saved, which is sufficient for a parameterless tool.
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 uses a specific verb ('Write') and identifies the exact resource ('snapshot of the learned model') and destination ('configured persistence'). This clearly distinguishes save_state from the logging and stats sibling tools, which concern training/match logs rather than model state.
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 the tool is used when an immediate, explicit save of the learned model is needed, and no sibling tool competes for this role. However, it does not state when to use it versus alternatives or mention any prerequisites, so usage guidance remains implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Train Drain3 with one log line and return its cluster and extracted parameters.
| Name | Required | Description | Default |
|---|---|---|---|
| log_message | Yes | ||
| extract_parameters | No |
| Name | Required | Description |
|---|---|---|
| matched | Yes | |
| template | No | |
| cluster_id | No | |
| parameters | No | |
| change_type | No | |
| log_message | Yes | |
| cluster_size | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the tool as non-read-only and non-idempotent, and 'Train Drain3' confirms a state-mutating operation. The description adds that training is per single line and that the call returns the cluster/parameters, but it does not disclose whether this mutates persistent state or requires prior initialization. No contradiction with 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?
A single sentence with the verb and target first, no filler or repetition. Every phrase ('one log line', 'cluster', 'extracted parameters') carries information about input or output.
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?
For a simple two-parameter tool with an output schema, the core call is adequately described. However, the lack of explicit sibling routing and the absence of any note on repeated training behavior or model state leave the description slightly incomplete in context. The output schema relieves it from documenting 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?
Context signals show 0% schema description coverage, so the description must add meaning beyond bare names. It does map log_message to 'one log line' and connects 'extract_parameters' to the return of extracted parameters, but it does not explain the boolean's effect when false or its default. This is only partial compensation for the missing schema descriptions.
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 names a specific action ('Train'), the target resource ('Drain3'), the input granularity ('one log line'), and the expected output ('cluster and extracted parameters'). The singular 'one log line' also implicitly separates it from the sibling 'train_logs'. This is specific enough for an agent to select it.
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 conveys a clear context: use this tool to train on exactly one log line and retrieve the resulting cluster and parameters. It does not, however, explicitly state when to prefer the plural sibling train_logs or exclude batch training, so the agent must infer the boundary from naming.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Train Drain3 with a batch of log lines in the provided order.
| Name | Required | Description | Default |
|---|---|---|---|
| log_messages | Yes | ||
| extract_parameters | No |
| Name | Required | Description |
|---|---|---|
| mode | Yes | |
| total | Yes | |
| changed | Yes | |
| matched | Yes | |
| results | Yes | |
| unmatched | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the operation as non-read-only and non-idempotent, so the description's lack of a mutation warning is acceptable. It adds value by noting order sensitivity, but it does not disclose whether training appends to or replaces existing model state, or whether a separate save_state call is required to persist the result.
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 short sentence with no filler. The core action, resource, input type, and order requirement are all front-loaded, and every word contributes.
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 is adequate for a simple batch-training call with an output schema and informative annotations, but it leaves out important operational context: what extract_parameters does, whether training is additive or replaces prior state, and whether persistence requires save_state. These are gaps an agent would benefit from knowing.
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?
With 0% schema description coverage, the description must compensate. It adds meaning for log_messages by calling them 'a batch of log lines in the provided order,' but it never explains the extract_parameters boolean, leaving the optional parameter semantically uncovered.
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 ('Train'), a concrete resource ('Drain3'), and an explicit input mode ('batch of log lines in the provided order'). This clearly sets it apart from the singular sibling train_log and the inference siblings like match_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 phrase 'batch of log lines' and 'provided order' give a clear context: this tool is for multi-line training where order matters, not for single-line training or matching. It does not explicitly name alternative tools or list exclusions, but the context is strong enough for an agent to select it.
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.
v0.1.0extract_log_parametersget_statslist_templatesmatch_logmatch_logssave_statetrain_logtrain_logsScored across 8 tools
Each tool maps to a distinct operation: training, matching, listing templates, extracting parameters, stats, and persistence. The singular/batch pairs are clearly differentiated by description.
All tool names follow a consistent verb_noun snake_case pattern, such as train_log, match_log, list_templates, and save_state. Minor length differences do not hurt predictability.
Eight tools is well-scoped for a Drain3-focused server. Each tool covers a necessary aspect of the log template mining workflow without redundancy beyond intentional singular/batch variants.
The core training, matching, template listing, parameter extraction, stats, and persistence workflows are covered. However, there is no explicit load_state or reset/clear operation, which leaves minor gaps in full lifecycle management.
Syslog receiver and MCP server for homelab log intelligence.
Syslog receiver and MCP server for homelab log intelligence.
MCP server for progressive tool usage at any scale (see https://klavis.ai)
