Klaxon is an MCP server that provides a natural language, read-only interface to a Wazuh 5 SIEM cluster, enabling plain-language investigation, schema analysis, decoder debugging, and diagnostic querying.
search: Run raw OpenSearch query DSL against any Wazuh 5 index pattern; returns full JSON with aggregations and a diagnostics block for empty or truncated results.
schema: List fields of an index and show which are actually populated, helping avoid aggregations on empty fields (e.g., agent.id vs. wazuh.agent.id).
field_coverage: Measure the percentage of documents carrying values per field, both in a time window and across the entire datastream, to detect normalization changes.
findings_overview: Pre-built summary of security findings by severity, agent, rule title, and category, needing no query DSL.
logtest: Push a raw log line through the decoder chain to see matched decoders, normalized output, and where the chain stopped; essential for debugging empty fields.
manager: Read-only passthrough to the Wazuh manager REST API (e.g., /agents) for agent and cluster info.
detectors: List or fetch OpenSearch Security Analytics detectors that produce findings.
tester_sessions: List available logtest environments to avoid "environment does not exist" errors (which return HTTP 200 with a buried error).
Enables querying OpenSearch indices, retrieving schema and field coverage, and running aggregations for security analytics investigation.
Click on "Install 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., "@klaxon Show me blocked connections by source country in the last 24 hours."
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.
The alarm tells you that. Klaxon tells you what.
Klaxon is a read-only proxy in front of your Wazuh 5 indexer. A language model asks questions in plain language; Klaxon queries the indexer, reads the schema, tests decoders, and reports what it actually found — including when it found nothing, and why. Works with Claude Desktop, Claude Code, local models through Ollama, and Open WebUI.
Every query runs through Klaxon, and the response is masked before it reaches
an external LLM: a value under a configured field (user.name, source.ip, …)
always becomes the same deterministic token ([USER_…], [IP_…]), aggregation
keys included. This is pseudonymization, not anonymization — tokens are
deterministic and reversible by anyone holding the salt (see
LLM-safety guarantees).
Wazuh 5.x indexer reachable over HTTPS (search/schema also work against 4.x)
Python 3.11+ or Docker
an MCP client — Claude Desktop, Claude Code, ollmcp, Open WebUI 0.6.31+
python3 -m venv .venv
.venv/bin/pip install klaxon-mcpOr build the Docker image (klaxon-mcp is the entry point):
docker build -t klaxon-mcp .export KLAXON_INDEXER_URL=https://indexer.example:9200
export KLAXON_INDEXER_USER=wazuh-readonly
export KLAXON_INDEXER_PASSWORD=...KLAXON_INDEXER_URL is the only required variable. Add KLAXON_MANAGER_URL for
manager/detectors and KLAXON_ENGINE_URL for tester_sessions; set
KLAXON_VERIFY_SSL=false only for a self-signed lab cluster.
Masking is off by default and opt-in:
export KLAXON_ANONYMIZE_EXTERNAL_LLM=true # mask tool output for external models
export KLAXON_ANONYMIZATION_SALT=change-me-to-a-long-random-secret # stable tokensWith the switch on, output is masked unless KLAXON_LLM_BASE_URL points at a
loopback address (http://localhost:11434 for Ollama) — a local model keeps
receiving unchanged data. An optional config.yaml (KLAXON_CONFIG) holds only
what you change; environment variables always win:
anonymization:
mask_fields: # or KLAXON_ANONYMIZATION_MASK_FIELDS
- "source.ip"
- "user.name"
- "host.hostname"
mask_aggregation_keys: true # ON by default; false disables agg-key maskingklaxon-mcp # stdio — your MCP client spawns it (klaxon is an alias)With Docker: docker run --rm -i --env-file .env klaxon-mcp.
Ask your client: "Show me the last login by user.name=alice in
wazuh-events-v5-*." Klaxon runs search(index="wazuh-events-v5-*", body=…) and returns the masked response:
{
"hits": { "hits": [ { "_source": {
"user": { "name": "[USER_9f2a1c467dd5e2b8]" },
"source": { "ip": "[IP_5c01e73f9a2b4c1d]" },
"message": "user [USER_9f2a1c467dd5e2b8] logged in via ssh from [IP_5c01e73f9a2b4c1d]"
} } ] }
}The same value always maps to the same token. Masking is pseudonymization, not
anonymization, and it has documented blind spots — see
docs/llm-safety.md (in particular the verified leaks in
"Known limitations") before pointing an external model at Klaxon.
Related MCP server: wazuh-mcp
The handful of tools a normal user needs (full reference:
docs/TOOLS.md):
Tool | What it does | One-liner example |
| Any query against any index, raw JSON back |
|
| Which fields exist — and which actually carry data |
|
| How complete each field is, window vs all history |
|
| Findings by severity, agent, title, category |
|
| Push a raw line through the decoder chain |
|
| Find sensitive fields the mask list should cover |
|
| Read-only security posture: facts + gaps, no verdict |
|
On an unfamiliar cluster, start with field_coverage. Every thin result gets a
notice block before the data (empty aggregation, capped size, missing index —
all return HTTP 200 with nothing).
The keys a normal user changes day to day. Full reference: docs/configuration.md.
Variable / key | What it does | Default |
| Indexer endpoint | — (required) |
| Basic-auth credentials | empty |
| Master masking switch |
|
| Secret for token derivation (stable tokens) | random+persisted |
| Fields masked wholesale ( | built-in list |
| Mask aggregation bucket keys too |
|
| Mask usernames inside free text |
|
| TLS verification |
|
| Required bearer token when serving over HTTP | empty |
The deep material lives in dedicated docs — linked, not duplicated:
GDPR plausibility checker (classification layers, custom rules, sampling, reports) → docs/gdpr-checker.md
Ingest masking / Option B masked stream (pipeline, ISM, index templates, quarantine for masking failures, sync job) → docs/option-b-masked-stream.md
Multi-tenant setup (fields.yaml, klaxon masking generate, salt, namespacing) → docs/multi-tenant.md
Drift prevention & CI (pre-commit drift hook, provenance fingerprints, fail-closed startup, sync preflight, --verify-config) → docs/drift-prevention.md
Token scheme & security model (HMAC, salt, self-test, why 16 hex) → docs/security-model.md
Security concept: brute-force re-identification risk (pseudonymization vs anonymization, salt as secret) → docs/security-concept.md
Salt rotation runbook (no scheduled rotation; only on suspicion; response-layer + masked-stream paths) → docs/salt-rotation-runbook.md
LLM safety: using Klaxon safely with an LLM (masked-stream-first routing, ready-to-copy system prompt, pseudonymization boundary, residual gate) → docs/llm-safety.md
Running it on another machine (HTTP transport, auth, TLS, CORS) → docs/TOOLS.md, ARCHITECTURE.md
.venv/bin/pip install -e ".[dev]"
.venv/bin/pytest # full suite
.venv/bin/mypy # strict type check
.venv/bin/ruff check srcOption B generator self-tests (see docs/drift-prevention.md):
klaxon masking selftest --tenant customer-a
klaxon masking generate --check # CI/pre-commit drift checkDeploy the masking artifacts to the indexer in one idempotent, ordered,
self-verifying step (preflight + GET-back verification + a _simulate smoke
test; --dry-run / --rollback):
klaxon masking deploy --tenant customer-a --dry-run # plan only, no writes
klaxon masking deploy --tenant customer-a # needs KLAXON_INDEXER_*Remove the Option B masking infrastructure from the indexer cleanly, leaving the
raw Wazuh streams untouched (destructive — preview with --dry-run; a
mandatory verification phase proves nothing klaxon-* is left and the raw
streams are intact):
klaxon masking teardown --tenant customer-a --dry-run # plan only, no writes
klaxon masking teardown --tenant customer-a --yes # needs KLAXON_INDEXER_*
klaxon masking teardown --tenant customer-a --yes --purge-sync-state
# ^ also delete the sync checkpoint marker (default: keep it so a future
# re-setup can resume from the last checkpoint)The live integration test (klaxon masking test) needs real indexer credentials —
see docs/option-b-masked-stream.md.
Release history: CHANGELOG.md.
docs/TOOLS.md — full tool reference & parameters
docs/configuration.md — complete configuration reference
docs/gdpr-checker.md — the GDPR plausibility checker
docs/option-b-masked-stream.md — ingest-side masking
docs/multi-tenant.md — multi-tenant setup
docs/drift-prevention.md — drift prevention & CI
docs/security-model.md — token scheme & security model
docs/security-concept.md — pseudonymization / brute-force re-identification risk
docs/salt-rotation-runbook.md — salt rotation runbook (only on suspicion)
docs/llm-safety.md — masking guarantees & limits
ARCHITECTURE.md — design rationale
CHANGELOG.md — release history
Apache-2.0 — see LICENSE.
Built by sec73 GmbH.
Wazuh is a registered trademark of Wazuh Inc. Klaxon is an independent project and is not affiliated with, endorsed by, or sponsored by Wazuh Inc.
List or fetch OpenSearch Security Analytics detectors.
Detection in Wazuh 5 lives in the indexer, not in the Engine. These detectors are what produces the documents in wazuh-findings-v5-*.
The plugin exposes no list-all endpoint, so list is implemented as
POST /_plugins/_security_analytics/detectors/_search with match_all. Detector
documents are nested under the detector path, which matters if you search
them by name.
Args: action: "list" for all detectors, "get" for a single one by id. detector_id: Required when action is "get". size: Maximum number of detectors to return for "list". Defaults to 50.
| Name | Required | Description | Default |
|---|---|---|---|
| size | No | ||
| action | No | list | |
| detector_id | 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 takes on the transparency burden. It reveals implementation details (POST /_plugins/_security_analytics/detectors/_search with match_all), response nesting, and the fact that these detectors produce wazuh-findings-v5-* documents. It does not explicitly mention side effects or permissions, but read-only behavior is strongly implied by 'List or fetch.'
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 well-structured and every sentence earns its place. It provides essential context, implementation notes, and a clear Args block. Despite being longer than average, the information is dense and relevant, with no fluff or repetition.
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 three-parameter tool with an output schema, the description is complete. It covers action semantics, parameters, defaults, implementation behavior, and the nested response structure. The output schema exists, so not detailing return values is acceptable.
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%, but the description fully compensates by explaining all three parameters: action's allowed values, detector_id's requirement when action is 'get', and size's purpose with a default. This adds meaning far beyond the bare schema.
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 clearly states the tool's purpose: 'List or fetch OpenSearch Security Analytics detectors.' It specifies the resource (detectors) and the two primary actions (list and get). It further differentiates from sibling tools by explaining that detectors in Wazuh 5 are indexer-based, providing unique context.
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 explicit guidance on when to use 'list' versus 'get' and notes that no list-all endpoint exists, so list is implemented via a search endpoint. It also clarifies that detector documents are nested under the 'detector' path, which is important for searching by name. This is strong practical guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Measure what share of the documents actually carries a value per field.
The normalisation-quality measurement, callable without query DSL. For each mapped field it reports the document count and coverage inside a time window and across the whole datastream, because those are different questions:
event.action, wazuh-events-v5-network-activity*
whole datastream (10,238,381 docs) 8.1%
last 24 hours (348,247 docs) 71.0%
last 12 hours 100.0%A decoder fix had landed hours earlier. All three numbers are correct. The window describes the pipeline as it runs now, the datastream describes the stored history — quote the one you mean. When they differ by more than 20 percentage points the diagnostics block says so explicitly, because that gap is the signature of a change in normalisation inside the datastream.
Fields with 0% coverage are listed, never filtered: mapped-but-never-
populated is the agent.id trap and the most important result this
measurement produces.
Coverage is three-valued — populated, not populated, not measurable. An exists aggregation returns 0 for a field the mapping declares "index": false no matter what the documents hold, so the mapping is read first and such fields are reported as not measurable, with dashes, never as 0%. Verified: event.original in wazuh-events-v5-network-activity* is index:false and doc_values:false, matches 0 of 10,243,389 documents, and carries the complete raw log line in _source of every document sampled. For those fields the tool samples _source and reports in how many of the sampled documents the key is present — evidence rather than a coverage figure.
Cost scales with the field count — the schema has 2351 fields — so the
listing is capped at KLAXON_SCHEMA_FIELD_LIMIT (default 200) and the cap is
reported. Pass a prefix to measure a namespace instead of a truncation.
Args: index: Index or datastream pattern, e.g. "wazuh-events-v5-network-activity*". prefix: Restrict to a field namespace, e.g. "source." or "wazuh.". hours: Size of the time window ending now, in hours. Default 24. min_docs: Hide fields below this document count in the window. Default 0, which hides nothing. Any higher value removes the 0% fields — the ones worth looking at — so the output says how many it dropped.
| Name | Required | Description | Default |
|---|---|---|---|
| hours | No | ||
| index | Yes | ||
| prefix | No | ||
| min_docs | 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. It thoroughly discloses behavior: fields with 0% are listed, never filtered; the three-valued coverage semantics; how index:false fields are reported as 'not measurable' with dashes and sampled from _source instead; cost scaling with field count and the truncation cap; and that min_docs hides fields and the output reports how many were dropped.
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 longer but every section earns its place. It opens with a clear summary, then explains the core distinction, the three-valued semantics, and cost/truncation. The Args section is formatted clearly. It could potentially be tightened, but the density of information is high and front-loaded with the most important facts.
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 the tool's complexity, 4 parameters, and an output schema, the description is remarkably complete. It covers output semantics, edge cases (index:false), cost considerations, parameter effects, and interpretation guidance. An agent has everything needed to call it correctly and interpret results.
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 compensates fully. It explains each parameter in the Args section, providing defaults, meanings, and examples. For index it gives an example, for prefix it shows namespace examples and purpose, for hours it specifies the time window size, and for min_docs it explains the default behavior and the consequence of setting it higher.
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 clearly states the tool measures field coverage in documents, a specific verb-resource combination. It distinguishes itself from siblings like search or schema by emphasizing it's a normalisation-quality measurement callable without query DSL, and details its unique three-valued coverage output.
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 explicitly explains when to use this tool versus alternatives, though it doesn't name siblings directly. It says it's for normalisation-quality measurement 'callable without query DSL', differentiates between whole datastream vs time-window coverage, warns about interpreting the gap, and explains the difference from a simple exists aggregation. It gives concrete usage context for the parameters like prefix to avoid truncation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Summarise wazuh-findings-v5-* by severity, agent, rule title and category.
A frozen query for the breakdown every report starts with, so that producing
it needs no valid OpenSearch query DSL. search still covers everything
else; this tool only removes the need to hand-write the one aggregation that
recurs.
Severity is wazuh.rule.level, a keyword holding a string — critical,
high, medium, low, informational — not a Wazuh 4.x numeric level. The whole
scale is printed in canonical order with an explicit 0 for the levels that
did not occur, because a terms aggregation returns only the values it found:
a missing critical bucket cannot distinguish "none occurred" from "never
populated". Any value outside the scale is listed as well and marked
UNKNOWN. Before aggregating, the tool probes whether wazuh.rule.level is
populated at all and says so instead of printing a table of zeros.
Output is a compact set of tables, not raw JSON. The request that produced
them is in the footer if you want to re-run or extend it via search.
Args: hours: Size of the time window ending now, in hours. Default 24. top_agents: How many agents to list, by finding count. Default 10. top_titles: How many rule titles to list. Default 10.
| Name | Required | Description | Default |
|---|---|---|---|
| hours | No | ||
| top_agents | No | ||
| top_titles | 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 so exceptionally. It discloses that severity is a string with a canonical order, that zero buckets are explicitly shown to avoid ambiguity, that unknown values are marked UNKNOWN, that the tool probes for field population, and that output is compact tables rather than raw JSON. This goes well beyond typical descriptions.
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 longer than a minimal one, but every sentence earns its place by explaining the rationale behind non-obvious behavior (e.g., explicit zero buckets, the probe before aggregation, output format). The structure is logical: purpose, usage, behavioral details, then args. Slightly verbose but not wasteful.
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 the tool's complexity and the absence of annotations, the description thoroughly covers purpose, parameters, output behavior, edge cases (missing levels, unknown values), and relationship to sibling tools. The output format is described even though an output schema exists, which helps set expectations. Nothing critical 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?
The input schema provides only types and defaults with 0% schema description coverage, so the description must compensate. It does: each parameter (hours, top_agents, top_titles) is given a clear meaning, unit, and purpose, and defaults are restated with context. This fully resolves what the parameters control.
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 opens with a specific verb and resource: 'Summarise wazuh-findings-v5-* by severity, agent, rule title and category.' It clearly distinguishes itself from the sibling tool 'search' by explaining it is a frozen query for 'the breakdown every report starts with' and that 'search still covers everything else.'
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 explicitly states when to use this tool: for the recurring aggregation that reports start with, and notes that 'search' covers everything else. This provides clear guidance on usage vs. alternatives, even naming the specific alternative and the scoping relationship between the two.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run the DSGVO plausibility check on an index: find sensitive fields.
Reads the index mappings, samples a few documents, and classifies the
fields by three heuristics in decreasing certainty: custom rules from
config.yaml (gdpr_checker.custom_patterns), field-name patterns
(source.ip, user.name, host.hostname, user.email, ...), and sampled
values (an actual value like 192.168.1.100 reveals an IP even when the
field name does not).
Priorities: IPs, usernames and e-mails are directly personal (high);
hostnames and agent ids are indirectly personal (medium); free-text fields
that embed personal data are flagged as such. Fields already in the
anonymization mask_fields are reported as covered, not re-suggested.
With apply=true the suggested fields are merged into
anonymization.mask_fields of config.yaml (KLAXON_CONFIG), the action is
appended to gdpr_check.log, and gdpr_compliance_report.json is
written. The change takes effect for the running server on restart unless
KLAXON_ANONYMIZATION_MASK_FIELDS is set, which always overrides the file.
apply=false (default) is a dry run: suggestions only, nothing changed.
Args: index: Index or datastream pattern, e.g. "wazuh-events-v5-*". prefix: Restrict to a field namespace, e.g. "user." or "source.". sample_docs: Documents to sample for content analysis. Defaults to KLAXON_GDPR_SAMPLE_SIZE (10). 0 disables sampling. apply: When true, merge the suggested fields into config.yaml and log. exclude: Field names to skip (e.g. internal fields without GDPR relevance). as_json: When true, return a machine-readable JSON report instead of the table.
| Name | Required | Description | Default |
|---|---|---|---|
| apply | No | ||
| index | Yes | ||
| prefix | No | ||
| as_json | No | ||
| exclude | No | ||
| sample_docs | 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 fully discloses behavior: reading mappings, sampling documents, using three heuristics, classifying fields into high/medium/flagged, handling already-covered fields, and explaining the apply=true side effects (config merge, logging, report writing, restart requirement, and environment override). This is exemplary transparency.
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 well-structured with clear paragraphs and an Args list. Every sentence contributes value: heuristics, priorities, apply behavior, and parameter details. It is detailed yet concise, with no wasted words or redundancy with 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?
For a complex tool with 6 parameters and significant side effects, the description covers all necessary contextual aspects: input parameters, heuristics, classification logic, side effects, environment variable override, and default behavior. Since an output schema exists, return value details are not required, but the description still mentions the report format and filenames.
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 becomes the sole source of parameter meaning. It compensates comprehensively by listing all six parameters in an Args section, explaining each one's purpose, defaults (e.g., sample_docs defaults to KLAXON_GDPR_SAMPLE_SIZE, apply defaults to false), and examples (index pattern, prefix format, exclude semantics).
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 explicitly states the tool 'runs the DSGVO plausibility check on an index: find sensitive fields.' It details three heuristics and clearly distinguishes itself from sibling tools (search, schema, etc.) by its unique GDPR-specific function.
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 on when to use this tool (for GDPR checks and finding sensitive fields) and explains the dry-run vs. apply modes. It does not explicitly mention alternatives or exclusions, but the purpose is unambiguous and self-contained.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read-only security/DSGVO posture check: facts + gaps, never a verdict.
Returns one check: status — fact line per item: masking, response gate,
mode (response-layer vs Option B masked stream), pipeline drift, salt
strength, quarantine backlog, RBAC roles, retention and the startup
fail-closed check. Statuses are OK / WARN / unknown only — there is no
overall compliance verdict and no legal judgment (the same principle as
gdpr_check: report what can be established, nothing more).
The salt is NEVER emitted — not even partially, not hashed. No PII, raw values, tokens, hostnames, usernames, IPs or sampled values appear in the output; only counts, booleans, statuses, index patterns, durations and role names. When the indexer is unreachable a check reports "unknown — " instead of a guessed value. Read-only: nothing is written to the indexer, nothing deployed, no config change.
Args: tenant: Tenant whose masked/quarantine streams and RBAC roles are checked (default "customer-a"). hours: Quarantine-backlog window in hours (default 24).
| Name | Required | Description | Default |
|---|---|---|---|
| hours | No | ||
| tenant | No | customer-a |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully carries the burden of behavioral disclosure. It explicitly states the tool is read-only, never emits the salt, omits PII, returns only counts/booleans/statuses, and reports 'unknown' when the indexer is unreachable. This goes far beyond a basic 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?
The description is detailed but every sentence earns its place: it covers output format, constraints, error behavior, and parameter semantics. The structure with paragraphs and an Args list is clear and appropriately front-loaded with the most critical safety guarantees.
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 tool has a rich output schema and complex behavior, and the description fully explains return values, statuses, and edge cases (e.g., unreachable indexer). It leaves no ambiguity about what the tool does, what it outputs, and what it avoids doing, making it complete for an agent.
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 input schema only provides titles and defaults, but the description's Args section explains the semantic role of each parameter (e.g., tenant specifies which masked/quarantine streams and RBAC roles are checked). This adds meaning beyond the schema, though it does not detail types or constraints beyond defaults.
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 clearly identifies the tool as a read-only security/DSGVO posture check that returns facts and gaps, never a verdict. It also distinguishes itself from the sibling gdpr_check by referencing the same principle, ensuring no confusion with similar tools.
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 when to use the tool (for posture checks) and references gdpr_check as a sibling with the same principle, offering some context. However, it does not explicitly state when to prefer this over other siblings or provide exclusions, so it is clear but not exhaustive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run a raw log line through the Wazuh 5 decoder chain and return the result.
Calls the Content Manager plugin on the indexer. The response shows which decoders matched and what the normalised WCS document looks like, which is the way to find out why a field is empty in the index.
Args:
event: The raw log line to decode.
location: Log source path, e.g. "/var/ossec/logs/opnsense_syslog.log".
queue: Queue id of the originating source. Defaults to 49.
space: One of test, custom, standard — logtest supports no others. Custom
decoders live in "custom"; "standard" carries only the shipped ruleset.
A valid name does not guarantee the environment is provisioned — use
the tester_sessions tool to see which ones exist and are enabled.
trace_level: One of NONE, ASSET_ONLY, ALL. Defaults to ASSET_ONLY, which
is the level that reveals the matched decoder chain. NONE returns the
normalised event only; ALL adds per-asset trace detail.
integration: Integration name for the detection phase. Without it the
plugin normalises the event and reports detection as "skipped".
| Name | Required | Description | Default |
|---|---|---|---|
| event | Yes | ||
| queue | No | ||
| space | No | ||
| location | Yes | ||
| integration | No | ||
| trace_level | 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 an excellent job. It discloses that the tool calls the Content Manager plugin on the indexer, explains the effect of trace_level values, and warns that without integration the detection phase is 'skipped.' It also notes that a valid space name does not guarantee the environment is provisioned, adding important behavioral context beyond the schema.
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 long but every sentence earns its place. It opens with the core purpose, then organises parameter details under a clear 'Args:' list. The prose about space and trace_level is dense but necessary. No filler or repetition exists.
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 the tool's complexity (6 parameters, no schema descriptions, no annotations), the description provides all needed context: what the tool does, what the output looks like, how parameters affect behavior, and where to go for related information. The output schema exists, so return values are covered. This is a complete, self-sufficient tool 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?
The schema has 0% description coverage, but the description fully compensates by explaining every parameter: event, location, queue, space, trace_level, and integration. It includes allowed values, defaults, and behavior for each, such as 'trace_level: One of NONE, ASSET_ONLY, ALL' and 'Defaults to ASSET_ONLY.' This goes far beyond the bare schema.
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 opens with a clear, specific action: 'Run a raw log line through the Wazuh 5 decoder chain and return the result.' It further explains the purpose by stating that the response shows which decoders matched and the normalised WCS document, positioning it as a diagnostic tool for field issues. This distinguishes it from sibling tools like search or findings_overview.
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 states both the context ('the way to find out why a field is empty in the index') and explicitly points to a sibling tool for complementary functionality: 'use the tester_sessions tool to see which ones exist and are enabled.' It also gives practical guidance about the integration parameter's effect on detection. This is strong when-to-use guidance with an explicit alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Issue a GET against the Wazuh manager API and return the response unchanged.
A deliberately thin passthrough. The manager API is the volatile half of Wazuh 5 and breaks further at GA (/var/ossec moves to /var/wazuh-manager, clustering becomes the default, agent id 000 disappears), so this tool adds no interpretation on top of it.
Non-2xx responses are returned as they are, status code included. In Wazuh 5 several 4.x endpoints are gone and their 404 is the correct answer, not a failure to hide:
/rules 404, the Engine has no RULE content type any more
/manager/logs 404
/manager/stats/remoted 404
Verified working: /agents, /syscollector/{agent_id}/...
Changed response schemas: /cluster/healthcheck (no enabled field),
/cluster/nodes (no node_type field).
The security root is restricted to /security/users/me and
/security/users/me/policies — enough to tell RBAC filtering apart from an
empty deployment when /agents returns less than expected, without
enumerating the deployment's accounts, roles and policies through a tool
meant for agent and event data.
Args: path: Manager API path, e.g. "/agents". params: Optional query parameters.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | ||
| params | 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 burden of disclosure. It thoroughly covers behavioral nuances: non-2xx responses are returned as-is, specific endpoints now return 404 which is correct, response schemas have changed, and the security root is deliberately restricted. This is exceptionally transparent about edge cases and limitations.
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 long but well-structured, with the purpose stated up front followed by relevant context, bullet points, and a clean Args section. The length is justified by the complexity and the need to explain the unusual passthrough behavior and API volatility. It is not excessively wordy—each sentence adds useful information.
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 passthrough tool, the description is remarkably complete. It explains the return behavior (unchanged, non-2xx as-is), lists verified working endpoints, documents changed response schemas, and clearly delimits the security scope. Since the tool returns responses unchanged and an output schema exists (likely generic), no further return-value detail is necessary. This fully equips an agent to use the tool appropriately.
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. The Args section gives a one-line explanation for each parameter: path with an example ('/agents') and params as 'Optional query parameters.' This adds basic meaning but does not detail the structure of `params` (free-form object) or provide format constraints. It meets the minimum threshold but leaves room for more specificity.
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 opens with a clear, specific statement: 'Issue a GET against the Wazuh manager API and return the response unchanged.' It identifies the verb (GET), the resource (Wazuh manager API), and the behavior (unchanged passthrough). It also distinguishes itself from sibling tools by explicitly stating it adds no interpretation, making its role unique.
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 raw API responses are needed, and it notes the API is volatile. It implicitly excludes security enumeration by restricting the `security` root and stating the tool is 'meant for agent and event data.' However, it does not explicitly name alternatives or give a direct 'use this instead of X' comparison, 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.
List the fields of a Wazuh 5 index and how many documents actually fill them.
Use this before writing any aggregation. The Wazuh 5 engine schema defines
2351 fields, and a mapped field is not necessarily a populated one: agent.id
and wazuh.agent.id are both mapped as keyword, but only wazuh.agent.id
ever carries a value. Aggregating on the wrong one returns zero buckets and
HTTP 200 — no error at all. With only_populated=true this tool reports the
document count per field, which makes that distinction visible.
Namespace sizes in the engine schema: wazuh=492, threat=444, process=391, file=144, tls=77, host=57, observer=53, dll=46, user=46, client=35, destination=35, server=35.
Args: index: Index or datastream pattern, e.g. "wazuh-events-v5-network-activity*". prefix: Restrict to a field namespace, e.g. "wazuh." or "source.". Strongly recommended — an unfiltered listing over 2351 fields is capped. only_populated: When true (default), issue a second pass with exists aggregations and return only fields holding a value in at least one document.
| Name | Required | Description | Default |
|---|---|---|---|
| index | Yes | ||
| prefix | No | ||
| only_populated | 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 full weight. It discloses the cap on unfiltered listings, the behavior of 'only_populated' (a second pass with exists aggregations), and the fact that aggregating on the wrong field returns HTTP 200 with zero buckets. These are key behavioral traits beyond simple function.
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 long but well-structured: purpose sentence, use-case context, namespace size reference, then parameter details. It is front-loaded with the core purpose and every sentence adds value, though the namespace size list could be seen as slightly tangential.
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 the tool's complexity, zero annotations, and no schema-level parameter descriptions, the description covers purpose, usage guidance, behavioral nuances, and parameter semantics thoroughly. The existence of an output schema means return value details are not needed in the description.
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 Args section provides thorough explanations for all three parameters, including examples like 'wazuh-events-v5-network-activity*' for index and 'wazuh.' for prefix, plus the default behavior of only_populated. Since the input schema has no descriptions for properties, this fully compensates.
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 opening sentence clearly states the tool's function: 'List the fields of a Wazuh 5 index and how many documents actually fill them.' It names a specific verb (List) and resource (fields of a Wazuh 5 index) and distinguishes itself from siblings like 'field_coverage' by focusing on populated vs. mapped fields.
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 explicitly directs users to 'Use this before writing any aggregation' and explains the pitfall of aggregating on a mapped but unpopulated field. It provides clear context and a strong recommendation for the 'prefix' parameter, though it does not explicitly state when not to use the tool or name alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run an OpenSearch query DSL request against a Wazuh 5 index pattern.
Returns the raw JSON response, including aggregations, preceded by a
diagnostics block when the result needs interpretation (zero hits, a
truncated total, or an aggregation that covers only part of the result set).
Common patterns:
wazuh-events-v5-* all events
wazuh-findings-v5-* all detection findings
wazuh-events-v5-* one of: access-management, applications, cloud-services, network-activity, other, security, system-activity, unclassified
These are datastreams. Always query the wildcard pattern, never a backing index such as .ds-wazuh-events-v5-network-activity-000001.
The time field is @timestamp. There is no timestamp field in Wazuh 5.
Set "track_total_hits": true whenever you need an exact count; without it
OpenSearch stops counting at 10000.
A "size" larger than KLAXON_SEARCH_MAX_SIZE (default 100) is lowered to that limit before the query is sent, and the diagnostics block says so. Use "size": 0 with aggregations to count without pulling documents.
The same cap applies to the size of bucketed aggregations (terms,
significant_terms, significant_text, multi_terms, composite, top_hits):
an oversized aggregation size is lowered to KLAXON_SEARCH_MAX_SIZE before
the query is sent and an "[AGG SIZE CAPPED]" diagnostics line names the
affected aggregation and its requested size, so a lowered bucket count is
never read as the real one.
When anonymization is enabled and KLAXON_ANONYMIZATION_MASK_AGGREGATION_KEYS
is on, aggregation bucket keys for masked fields (terms, multi_terms,
composite) are replaced with the same deterministic tokens as the _source
pass — so aggregation keys and hits stay aligned for the same entity.
Args: index: Index or datastream pattern, e.g. "wazuh-events-v5-network-activity*". body: OpenSearch query DSL as a JSON string.
| Name | Required | Description | Default |
|---|---|---|---|
| body | Yes | ||
| index | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided (readOnlyHint, destructiveHint absent), the description carries the full burden. It discloses: returns raw JSON with a diagnostics block when needed, caps size at KLAXON_SEARCH_MAX_SIZE, caps aggregation sizes, and anonymizes bucket keys when enabled. It even mentions the '[AGG SIZE CAPPED]' diagnostics line. This is extensive behavioral disclosure covering data transformation, limits, and conditional output.
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 long but each paragraph earns its place: the first gives the core purpose and diagnostics, the second lists common patterns, the third covers constraints (time field, track_total_hits, size cap), the fourth covers aggregation sizing, and the fifth covers anonymization. It front-loads the core purpose and the diagnostics. A minor deduction because the lsit of patterns and the anonymization paragraph could be trimmed or merged, but it's well-structured and not redundant.
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 there's an output schema, the return format is already defined. The tool is complex (2 parameters, high behavioral complexity with caps, anonymization, diagnostics), and the description covers: index patterns and constraints, time field naming, track_total_hits semantics, size caps for both hits and aggregations, anonymization behavior, and the diagnostics block. There's nothing an agent needs to correctly call this tool that is missing. The description is complete for its complexity.
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% (no descriptions in the input schema) and there are only two params: index and body. The description explains index thoroughly (patterns, wildcard requirement, datastream naming) and body as 'OpenSearch query DSL as a JSON string'. It doesn't elaborate on the body's structure beyond that, but body is generic DSL where the user must provide the JSON. The description adds meaning for index beyond the schema (which only says 'string') and a reasonable definition of body.
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 clearly states the verb ('Run an OpenSearch query DSL request') and the resource ('Wazuh 5 index pattern'). It strongly distinguishes itself from siblings—while 'schema' likely describes the index schema and 'findings_overview' summarizes findings, this tool runs raw DSL queries. The description is specific about the API target, making it unmistakable.
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 explicit usage guidance: which index patterns to use, to use wildcard patterns rather than backing indices, to set track_total_hits for exact counts, and to use size:0 with aggregations. It also warns against the wrong approach (backing index) and provides concrete examples of patterns. It doesn't explicitly name sibling alternatives, but the 'when to use' guidance is so complete that an agent knows exactly when this tool is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the Wazuh 5 engine test sessions — the environments logtest can use.
logtest answers a call naming an environment that does not exist with
HTTP 200 and "The '' environment does not exist" buried in the body.
This tool is how to find out which environments there actually are, and
whether they are enabled.
Calls POST /_internal/tester/table/get on the engine's internal HTTP API. That server runs inside the manager container on its own port, so it needs KLAXON_ENGINE_URL — the indexer and manager URLs do not reach it.
Read-only by design. The engine also exposes session/post, session/delete and session/reload; none of them are wired up here. Sessions are recreated on every policy import through the Content Manager API, so a hand-made session disappears at the next import — a create tool would only invite a workaround that does not hold.
Args: action: Only "list" is supported.
| Name | Required | Description | Default |
|---|---|---|---|
| action | No | list |
| 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 discloses the HTTP endpoint, the need for KLAXON_ENGINE_URL, the read-only nature, and the lifecycle of sessions (recreated on policy import). This is thorough behavioral disclosure beyond what any schema could convey.
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 detailed but every sentence earns its place. It front-loads the core purpose, then explains the failure mode, the API call, the URL requirement, and the design rationale. Slightly long but justified given the complexity and lack of annotations.
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 the tool's complexity (internal API, environment variable requirement, misleading error behavior), the description covers everything an agent needs: what it does, when to use it, how it works, and why alternatives are absent. The output schema exists, so return format is covered elsewhere. 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 coverage is 0%, so the description must compensate. It does: it explains the only parameter 'action' supports only 'list'. This fully documents the parameter's meaning and constraints, though it could have been more explicit about the default value. Still, it adds significant value beyond the bare schema.
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 clearly states the tool lists Wazuh 5 engine test sessions, which are the environments logtest can use. It distinguishes itself from siblings by explaining its role relative to logtest and the internal API. The verb 'list' and resource 'test sessions' are specific and unambiguous.
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 explicitly explains when to use this tool: to discover which environments exist and whether they are enabled, especially when logtest returns a misleading success response. It also explains why create/delete/reload tools are not provided, preventing misuse. This is exemplary usage guidance.
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. Dates show when Glama detected each change.
v0.2.0klaxon_posture_checkgdpr_checkv0.1.0detectorsfield_coveragefindings_overviewlogtestmanagerschemasearchtester_sessionsEach tool has a clear, distinct purpose: search runs raw queries, schema lists fields, logtest decodes raw logs, manager is a thin API passthrough, detectors lists security analytics detectors, tester_sessions lists test environments, findings_overview generates a fixed findings summary, and field_coverage measures field population. There is no meaningful overlap between them.
Names are all lowercase snake_case, but they mix nouns (schema, manager, detectors, tester_sessions, findings_overview, field_coverage) and verbs (search, logtest). There is no consistent verb_noun pattern across the set, though the names are still descriptive and readable.
With 8 tools, the server falls within the ideal 3-15 range. Each tool covers a distinct aspect of Wazuh 5 exploration, from low-level querying to high-level summaries, without unnecessary redundancy.
The tool surface provides strong coverage for read-only exploration: querying, schema discovery, log decoding, manager API access, detector listing, session enumeration, and standard aggregations. Missing are write operations (create/update/delete) and a dedicated index listing tool, but these are likely intentional for a read-only server and can be worked around with search.
The BigQuery remote MCP server is a fully managed service that uses the Model Context Protocol to connect AI applications and LLMs to BigQuery data sources. It provides secure, standardized tools for AI agents to list datasets and tables, retrieve schemas, generate and execute SQL queries through natural language, and analyze data—enabling direct access to enterprise analytics data without requiring manual SQL coding.
MCP server providing access to the Scorecard API to evaluate and optimize LLM systems.
MCP server for building and testing AI agents with multi-model experimentation and insights.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/sec73/klaxon'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
