Skip to main content
Glama

Netmon (demo)

netflow_search

Read-onlyIdempotent

Search the FULL NetFlow history: the raw flow table (the last ~15 minutes) unioned with the aggregated rollup (4 weeks of history), windowed and pro-rated server-side. Wraps GET /api/aggnetflow/list (permission: vne). For per-flow packet counts and exact timing, use netflow_raw_search instead — that's the right drill-down once this tool surfaces an interesting src/dst pair, but it only reaches back about 15 minutes.

IP filters: src_ip and dst_ip are STRICT equality on that one column and NEVER match the opposite side. When you don't already know which side of the conversation the host sat on, use the compound ip filter (src_ip OR dst_ip) — reaching for src_ip instead silently drops every conversation where the host was the destination. Passing both src_ip and dst_ip ANDs them into a single direction.

Port filters: dst_port is strict equality; src_port is matched with ANY against the aggregated src_ports[] array, because this table has no scalar src_port column. The compound port matches dst_port OR src_ports[] ANY.

Window semantics: the predicate is OVERLAP — any flow ACTIVE during the window matches, including one straddling either edge — and every row carries TWO byte figures: window_bytes (the row's bytes pro-rated to the query window, assuming a uniform rate) and bytes (the row's own full count: for an aggregated row a SUM, with start_time a MIN and end_time a MAX over every flow folded in). Sum window_bytes for in-window bandwidth — quoting bytes for that over-reports edge-straddling conversations. is_raw marks which arm of the union produced a row. There is no packets column here. Direction is normalized on BOTH arms: the lower-numbered port of each conversation becomes dst_port (raw rows are re-oriented the same way on read), so dst_ip is the service side and src_ip the client side regardless of who sent the first packet.

Window: hours (default 24) OR start_time+end_time; this tool always sends an explicit window, so the controller's no-window fallback (conversations still open right now) never applies. limit defaults to 50; total is the full match count. Narrow via IP/port/protocol when truncated.

Tag-scoped server-side on the conversation ENDPOINTS — src_ip / dst_ip against the caller's in-tag device IPs, not flow_src.

Example: netflow_search({ip: '10.0.0.5', dst_port: 443, hours: 1})

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
ipNoCompound: matches src_ip OR dst_ip. Prefer this over src_ip/dst_ip whenever the host's side is unknown.
portNoCompound: matches dst_port OR src_port (via src_ports[] ANY).
vlanNoVLAN id.
hoursNoLookback hours (1-168). Default 24.
limitNoMax rows (1-500). Default 50.
dst_ipNoStrict equality on dst_ip alone — never matches a host sitting on the src side. Use `ip` unless you know the direction.
src_ipNoStrict equality on src_ip alone — never matches a host sitting on the dst side. Use `ip` unless you know the direction.
dst_portNoDestination port (strict equality). After rollup this is the LOWER port of the conversation, i.e. the service port.
end_timeNoISO-8601 UTC; pairs with start_time.
flow_srcNoIP of the device that exported the flow.
in_ifaceNoIngress SNMP ifIndex on the exporting device, e.g. "5". A number, not an interface name and not an interfaces.id.
protocolNoIP protocol NUMBER, e.g. "6" (TCP), "17" (UDP), "1" (ICMP). The column is an integer — protocol names are rejected by the database.
src_portNoSource port (matched via ANY against the aggregated src_ports[] array).
out_ifaceNoEgress SNMP ifIndex, e.g. "7". A number, not an interface name.
start_timeNoISO-8601 UTC; pairs with end_time.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A5/5.0
Behavior5/5

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

Annotations already declare read-only/idempotent behavior, and the description goes well beyond that: union arms, OVERLAP window semantics, pro-rated window_bytes vs full bytes, direction normalization, lack of a packets column, and tag scoping on endpoints. It even names the wrapped endpoint and required permission.

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?

Long but information-dense; each paragraph addresses a distinct correctness concern such as filter semantics, window behavior, output interpretation, and scoping. The most important sibling distinction is front-loaded, and nothing reads as filler.

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 complex search tool with no output schema, the description explains both request semantics and key response fields: window_bytes, bytes, is_raw, and total. It also covers tag scoping, authorization, and truncation guidance, giving the agent everything necessary to invoke and interpret results correctly.

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?

Although the schema covers 100% of parameters, the description adds crucial meaning the schema cannot: strict vs compound matching, src_port ANY semantics, dst_port as the lower port, hours OR start_time/end_time, and the meaning of `total` and `limit`. The example further anchors correct usage.

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 opens with a precise verb and resource: 'Search the FULL NetFlow history' via a union of raw and rollup data. It also explicitly distinguishes itself from netflow_raw_search by scope and use case, so an agent can immediately tell them apart.

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?

It explicitly names netflow_raw_search as the drill-down alternative and states the conditions for choosing it: per-flow packet counts and exact timing. It also provides concrete filter guidance, such as preferring the compound `ip` filter unless the host's side is known.

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.