Skip to main content
Glama
xinqihuang

Drain3 MCP Server

by xinqihuang

extract_log_parameters

Read-onlyIdempotent

Extract variable values from a log message by matching it against a provided template pattern. Returns the parsed parameters for further analysis.

Instructions

Extract variable values from a log line using a Drain3 template.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
log_messageYes
log_templateYes
exact_matchingNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
matchedYes
templateYes
parametersNo
log_messageYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

B3.3/5.0
Behavior3/5

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.

Conciseness5/5

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.

Completeness3/5

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.

Parameters2/5

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.

Purpose4/5

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.

Usage Guidelines3/5

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.