ATK Security Checks

Test Wazuh rule on a real manager

test_wazuh_rule

Read-onlyIdempotent

Runs log lines through a real wazuh-manager 4.14.9 (fresh logtest session) with your custom rules and decoders: which decoder and rule matched, whether YOUR rule fired, and load warnings such as 7617/7619. Logtest engine: frequency/timeframe rules and some live-only behaviour are out of scope. Free: 1 log line with your files (3 with the stock ruleset only), summary. 10 lines with decoded fields and full alerts: POST https://atkvn.com/agent/v1/wazuh-testfire (x402, USD 0.10).

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "logs": "<logs>"
    },
    "name": "test_wazuh_rule"
  }
}

Input Schema

Name	Required	Description	Default
`logs`	Yes	Raw log lines exactly as the agent would forward them, one event per item.
`rules`	No	Optional custom rule files: [{"filename": "0096-local.xml", "xml": "<group>...</group>"}]. Filename order matters: files load by name together with the stock ruleset.
`decoders`	No	Optional custom decoder files, same shape as rules.
`log_format`	No	Wazuh log_format, e.g. syslog or json.	syslog

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 22, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Annotations already cover the read-only/idempotent/non-destructive profile, and the description adds substantial extra context: a fresh logtest session per call, the specific warning codes surfaced (7617/7619), the limitations of the logtest engine, and the paid-tier gate with price and endpoint. The free-vs-paid line counts are exactly the kind of behavioral constraint an agent cannot get from annotations or schema.

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?

Front-loaded with the core action and output, then scope limits, then pricing; every sentence carries information. The final pricing sentence is dense (URL, payment protocol, amount packed together) and slightly harder to parse than the rest.

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?

For a no-output-schema tool, the description spells out what comes back (decoder/rule match, whether the user's rule fired, load warnings), what the engine cannot model, and how cost tiers work. An agent has everything needed to decide to call it and to interpret the response.

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?

Schema coverage is 100%, so the baseline is 3, but the description adds real meaning: the 'logs' budget varies depending on whether custom files are supplied, and 'rules'/'decoders' are framed as optional custom files loaded alongside the stock ruleset. It still adds no detail on log_format handling or how filename ordering affects results beyond what the schema already says.

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?

States a specific verb and resource: running log lines through a real wazuh-manager 4.14.9 logtest session with custom rules/decoders, and names the concrete outputs (matched decoder/rule, whether YOUR rule fired, load warnings). The emphasis on 'real manager' and 'fresh logtest session' implicitly separates it from the static-analysis sibling audit_wazuh_rules.

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

Usage Guidelines4/5

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

Gives clear invocation context, including engine scope exclusions ('frequency/timeframe rules and some live-only behaviour are out of scope') and per-call line budgets (1 log line with your files, 3 with stock ruleset only, 10 paid). It never explicitly names audit_wazuh_rules or another sibling as the alternative, so it stops short of full when/when-not routing.

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

All ATK Security Checks tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?