Skip to main content
Glama

Netmon (demo)

syslog_facets

Read-onlyIdempotent

Top-N value counts for ONE syslog field over a window — 'what are the top actions/reasons on this FortiGate in the last 2 hours' in a single call, instead of pulling rows and counting them yourself. Wraps GET /api/syslog/facets (permission: logs); tag-scoped server-side.

group_by takes one of two kinds of field:

COLUMN (indexed, may run fleet-wide — device_id optional): facility, severity, source

MESSAGE FIELD (parsed out of the message text at read time — device_id REQUIRED): action, reason, devname, type, subtype, level, logdesc, msg, service, policyid, srccountry, dstcountry, srcintf, dstintf, user, group, status, app, appcat, vpntunnel, eventtype, proto

Message fields have no index and cannot get one — they are pulled out of free text — so every message pivot is a sequential scan of the window (~37x the per-row cost of a column pivot). device_id is mandatory for them and the server rejects a fleet-wide message pivot outright.

devname and source are DIFFERENT keys and are deliberately not merged: source is the column syslog arrived with (a relay may have rewritten it to its own name), devname is what the device wrote about itself inside the message. Ask for the one you mean.

Window: hours (1-168, default 24) OR start_time+end_time (ISO-8601 UTC); a window wider than 168h is refused either way. limit is the top-N cut (1-50, default 20).

Reading the result: facets is the top-N; other is everything below the cut, so facets + other sums to matched_rows. rows_without_field counts rows in the window where the field is absent entirely — a large value is normal (a FortiGate emits many message types) and is NOT a failure.

Errors are structured, and two of them are instructions: error='window_too_large' — the row pre-check refused before scanning. Lower hours (halve it and retry) or add/narrow device_id. rows_in_window and max_rows tell you how far over you are. Do NOT retry the same window. error='query_timeout' — the scan passed the 10s server budget. Same remedy: narrow the window, or pivot a column instead.

Example: syslog_facets({group_by: "action", device_id: 372, hours: 2})

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
hoursNoLookback window in hours (1-168). Default 24.
limitNoTop-N cut (1-50). Default 20; the rest is folded into `other`.
end_timeNoISO-8601 UTC. Must be paired with start_time.
group_byYesField to pivot on. Columns: facility, severity, source (device_id optional). Message fields: action, reason, devname, type, subtype, level, logdesc, msg, service, policyid, srccountry, dstcountry, srcintf, dstintf, user, group, status, app, appcat, vpntunnel, eventtype, proto (device_id REQUIRED).
device_idNoDevice id to pivot within. Required for every message-field group_by; optional for facility/severity/source.
start_timeNoISO-8601 UTC (e.g. 2026-04-23T10:00:00Z). Must be paired with end_time.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.9/5.0
Behavior5/5

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

Beyond the readOnlyHint annotations, the description discloses critical behavior: for message fields, device_id is required and server rejects fleet-wide pivots, scans are sequential and ~37x costlier, and limits like 10s timeout are exposed. It also explains how to interpret results and common errors, providing deep behavioral insight.

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 detailed and organized with clear sections, but it is relatively long. However, every section adds value—from usage, to parameter details, to error handling—and is front-loaded with the most important context. Slightly verbose but justified for the complexity.

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, the description is remarkably complete: it covers purpose, parameters, constraints, performance implications, result interpretation, and error handling. With no output schema, it explains the output structure, making it fully self-contained for correct invocation.

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

Parameters5/5

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

The schema already has 100% coverage, but the description enriches it substantially: it categorizes fields into columns vs message fields, explains the difference between devname and source, clarifies window constraints (168h) and error handling, and gives examples of valid parameter combinations. This is far beyond schema basics.

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: to get top-N value counts for one syslog field over a window, with a concrete example and alternative approach. It distinguishes itself from row-pulling and syslog_search by focusing on aggregated facets, making it clear what this tool uniquely offers.

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 provides explicit guidance on when to use this tool and when not to, including specific scenarios like wide windows versus narrow, and when to use device_id. It also contrasts with pulling rows manually and suggests alternatives for wide scans, making usage context clear.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.