Skip to main content
Glama
Jambozx

OnlineCyberTools MCP (280+ filterable tools)

linux_log_parser

Read-onlyIdempotent

Parse Apache, nginx, syslog, JSON Lines, and systemd journal logs into structured rows, then filter, aggregate, or convert them for analysis.

Instructions

Linux Log Parser and Analyzer. Parse Apache (Common and Combined), nginx access, syslog (RFC 3164 and RFC 5424), JSON Lines, and systemd journal export logs into structured rows, then filter, aggregate, or re-export them. Format auto-detection picks the best parser, or supply a custom regular expression. Use linux_disk_usage_calculator instead for du or df output, or json_path_evaluator for querying a single JSON document. The operation field selects the stage: parse text into entries, filter those entries with a mini-language, aggregate them into counts or sums, convert them to JSON CSV or TSV, or list built-in analysis presets. Runs locally on the text you provide: read-only, non-destructive, reads no files, contacts no external service, and is rate-limited (30 requests/minute for anonymous callers). Input is capped at 5 MB. Returns the parsed entries with their field names and any warnings, or the filtered, aggregated, converted, or preset payload for the chosen operation.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
operationNoPipeline stage to run. parse turns raw log text into entries (default). filter narrows entries with an expression. aggregate groups entries into a metric. convert serialises entries to a chosen format. presets lists built-in analysis recipes and ignores all other fields.parse
textNoRaw log text to parse, one record per line (parse operation). Capped at 5 MB; larger input is truncated with a warning. Required for the parse operation.
formatNoLog format for the parse operation. auto scores every built-in parser and picks the best match. custom applies customPattern. Used only when operation is parse.auto
customPatternNoJavaScript regular expression applied per line when format is custom. Named capture groups become field names; otherwise groups are named group1, group2 and so on. Used only when operation is parse with format custom.
entriesNoArray of already-parsed entry objects (the parse result entries). Required for the filter, aggregate, and convert operations; non-object items are ignored.
expressionNoFilter mini-language for the filter operation. Each clause is a field plus a comparison operator plus a value; combine clauses with the word AND surrounded by spaces. Supported operators are equals, not-equals, regex-match, regex-not-match, greater-than, less-than, greater-or-equal, and less-or-equal. Regex operators are case-insensitive. An empty expression returns all entries.
byNoEntry field name to group on for the aggregate operation (for example ip, status, or uri). An empty value yields no groups.
metricNoAggregation metric for the aggregate operation. count tallies entries per group; sum, avg, min, and max are computed over the numeric field values.count
fieldNoNumeric entry field aggregated by sum, avg, min, or max in the aggregate operation (for example size). Ignored when metric is count.
aggregateNoOptional nested object form of the aggregate settings; when present it supersedes the top-level by, metric, and field fields.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
successNoTrue when the operation completed without error.
operationNoEcho of the operation that was run.
resultNoOperation payload. For parse: entries, fieldNames, format, warnings. For filter: result (array of matching entries). For aggregate: groups, metric, by, field. For convert: result (the serialised string). For presets: presets (array of recipe objects).
Behavior5/5

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

The description adds significant behavioral context beyond annotations, including rate limits (30 req/min), input size cap (5 MB), local execution, and that format auto-detection is used. It confirms read-only and non-destructive nature, aligning 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.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured with clear sections, but is somewhat lengthy. It could be slightly more concise without losing essential information. However, every sentence contributes to understanding, and key points are front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (10 parameters, multiple operations, output schema exists), the description covers purpose, usage, alternatives, operations, safety, and limitations. It is complete enough for an agent to correctly select and invoke the tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 100% schema coverage, the description adds moderate value by explaining operation stages contextually and detailing parameter usage such as the filter mini-language and aggregate settings. It clarifies required parameters for different operations, enhancing understanding beyond schema descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: parsing various log formats (Apache, nginx, syslog, JSON Lines, systemd journal) into structured rows, then filtering, aggregating, or converting them. It explicitly distinguishes itself from sibling tools linux_disk_usage_calculator and json_path_evaluator by specifying alternative use cases.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly tells when to use this tool (for log parsing and analysis) and when not to (for du/df output or single JSON documents, directing to alternatives). It also clarifies that it runs locally on provided text and is safe (read-only, non-destructive).

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/Jambozx/onlinecybertools-mcp-server'

If you have feedback or need assistance with the MCP directory API, please join our Discord server