"WEMO" matching MCP tools:

• search_ipA

  Netmon (demo)A

  Find every mention of a specific IP across Netmon's log and telemetry streams: syslog, Windows eventlog, Suricata EVE, aggregated NetFlow, and ARP. Returns one bucket per stream with {total, samples}. Streams that 4xx (e.g. 403 from tag-scope) show up in `skipped` so a partial result is still actionable. The syslog/eventlog streams match the IP via an unindexed message substring scan; on a high-volume install they can time out and land in `skipped` with guidance (narrow `hours`, or use syslog_search/eventlog_search with a device_id) rather than stalling the call. Params: - ip (required): IPv4 or IPv6 to correlate. - hours: lookback window (1-168, default 24). - per_stream: sample row cap per stream (1-100, default 10). The `total` per stream is always the full match count. - streams: narrow the fan-out to a subset — any of ['syslog','eventlog','eve','netflow','arp']. Omit for all. Permission + tag-scope checks run server-side; a tag-restricted user sees only rows for devices in their tag set. Example (narrow + short window): search_ip({ip: "10.10.1.25", hours: 1, streams: ["syslog"], per_stream: 5})

  ConnectorNo auth

• netflow_searchA

  Netmon (demo)A

  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})

  ConnectorNo auth

• alerts_historyA

  Netmon (demo)A

  Authoritative 'what fired and when' stream — wraps the `alert_history` table (one row per incident, both legacy and modern) and `alert_outlet_log` (per-dispatch ledger keyed by history_id). Default mode: lists incidents newest-first. Each row is one incident with opened_at / last_event_at / resolved_at framing the lifecycle, plus aggregated outlet_types[], dispatch_count, and failed_count. `status` is computed from resolved_at: 'open' if null, 'resolved' otherwise. Drill-down mode: pass `incident_id` (the `alert_history.id`, NOT `alert_id`) to switch the call to /api/alert-history/{id}/log and return the per-outlet dispatch ledger for that one incident. Use this for 'did the email actually go' / 'what did the webhook payload look like' / 'which outlets failed' follow-ups. Filters (default mode, all client-side, AND-combined): status (open|resolved|all, default all), severity (int or array — scheme is 1-5, lower=worse), device_id, source (legacy|modern|all), hours (1-168, default 24, applied against last_event_at), search (substring on alert_label/subject). Important caps: the upstream endpoint returns at most 500 rows ordered by last_event_at DESC. We can't reach older rows than that. `meta.upstream_cap` reports this so the LLM can warn the user when results may be truncated. `severity_label` is added server-side so the LLM doesn't memorize the scale. Pagination is over the post-filter result. Tag-scope is enforced by Laravel — tag-restricted users see only incidents for devices in their slug set. Permission: alerts. Examples: alerts_history({status: 'open', severity: [1,2], hours: 1}) alerts_history({device_id: 42, hours: 24}) alerts_history({incident_id: 9182}) // dispatch ledger

  ConnectorNo auth

• top_bandwidthA

  Netmon (demo)A

  Top NetFlow conversations over the last N minutes — the 'who's eating bandwidth right now?' question. Wraps GET /api/getTopBandwidth/{mins}, the same query that powers the dashboard live widget. Use this for short-window 'right now' inquiries. For longer windows (hours-to-days) or filtered top-talkers, use netflow_search instead — that tool has the rich filter set; this one is the live snapshot. Server-side cap: top 20 conversations by in-window bytes descending. We don't expose `top_n` — the upstream endpoint hardcodes the limit and there's no value in lying about that to the LLM. Each row: {src_host, src_id, src_ip, dst_host, dst_id, dst_ip, bytes, bps}. Hostnames come from the _dns view (PTR + custom overrides); src_id/dst_id are populated when the IP matches a monitored device. bytes is the conversation's in-window share (pro-rated), and bps is averaged across the window — not a live rate. Permission: vne. Examples: top_bandwidth({minutes: 5}) top_bandwidth({minutes: 60})

  ConnectorNo auth

• syslog_facetsA

  Netmon (demo)A

  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})

  ConnectorNo auth

• flow_summaryA

  Netmon (demo)A

  Summarize one host's network conversations: top peers, top ports, and a client-vs-service-side split, each with a residual "other" bucket plus overall totals. Wraps GET /api/aggnetflow/summary (permission: vne). Use this to characterize a host before pulling rows — netflow_search returns the individual conversations once a rollup here points at an interesting peer or port. Source is the windowed flow view: the raw table's live tail (the last ~15 minutes — cleanup_netflow deletes raw rows as it rolls them up) unioned with the aggregated history (agg_netflow, retained 4 weeks), so one call covers right-now through a month back with no gap at the rollup boundary. Byte totals are IN-WINDOW estimates, not lifetime totals. The window predicate is OVERLAP — a conversation crossing either edge still matches — but each matching row contributes only its bytes pro-rated to the window (uniform-rate attribution), so the totals approximate window traffic instead of bounding it from above. Still never quote a byte figure as a rate. Direction is normalized on both arms (the lower port of each conversation becomes dst_port — raw-tail rows are re-oriented the same way on read) and the rollup folds BOTH directions into one row, so sent-vs-received bytes do not exist in this data. The direction split is as_source (host was the client side) vs as_destination (host was the service side), each carrying bidirectional bytes. `conversations` counts rows, not distinct conversations — a long-lived conversation contributes one row per 15-minute roll-up tick, plus per-flow rows for its not-yet-rolled-up raw tail. Window: `hours` (default 24, max 168) OR start_time+end_time; an explicit window is held to the same 168-hour ceiling server-side — agg_netflow is BRIN-indexed on time now, but a summary still aggregates every overlapping row under a 10s statement timeout. A window too wide comes back as an error asking you to narrow it, not as partial data. `limit` is the top-N per rollup (default 20, max 100); what falls outside it is reported in that rollup's `other` bucket, so totals always reconcile. Tag-scoped server-side on the conversation ENDPOINTS: for a tag-restricted caller every returned conversation has an in-tag device on one side. The requested host gets no separate membership test, so naming an out-of-scope host is allowed and simply returns the subset of its conversations that touch a device you can already see. Example: flow_summary({ip: '10.0.0.5', hours: 24, limit: 10})

  ConnectorNo auth

• maintenance_windows_listA

  Netmon (demo)A

  Lists maintenance windows — the suppression schedules that gate alert dispatch. Use when a user asks 'why didn't this page me' or 'is this device under maintenance right now' — a quiet alert may be inside a window rather than truly silent. Two modes: - Global catalog (default): wraps GET /api/alerts/maintenance-windows. Returns every window with its schedule fields. - Per-legacy-alert: pass `alert_id` to wrap GET /api/alerts/legacy/{id}/maintenance-windows, returning only the windows attached to that legacy alert handler. Per CLAUDE.md, modern alerts (class=syslog_log/event_log/eve_log) attach windows through `alert_routing_rules`, not directly — the per-alert path is legacy-only by route constraint. If you need to inspect modern-alert suppression, look at the routing rule attached to the rule, not the alert. Each row carries: id, label, recurrence_unit (day|week|month|dawom), schedule_hour, schedule_dow (0=Sun..6=Sat), schedule_day_of_month, schedule_month, duration_minutes, plus a human-readable `description` (e.g. 'Weekly on Tue at 14:00 UTC for 60 min') so the LLM doesn't reinterpret the cron-style fields. Note: this tool does NOT compute whether a window is active *right now* — that depends on the server's local clock and the interpretation of dawom rules. The LLM should use the description + duration to reason about it. If you need a reliable yes/no, ask alertmond directly via its IPC (out of scope for mcpmond). Permission: alerts. Examples: maintenance_windows_list({}) // global catalog maintenance_windows_list({alert_id: 17}) // legacy alert 17 only

  ConnectorNo auth

• arp_tableA

  Netmon (demo)A

  Lists hosts observed on the local LAN(s) via the ARP table — the 'what devices have we seen recently?' question. Wraps POST /api/getArpTable, which collapses arptable + _dns into one row per IP with hostname + monitored-device id resolution attached. Distinct from `arp_lookup` (single-IP MAC resolution at the current moment): this is the historical view over the last N hours. Use it for 'who's on the LAN today' / 'is there a new device' / 'where did this IP last appear' questions. Each row: {id, ip, mac, timestamp, hostname, device_id}. device_id is non-null when the IP corresponds to a monitored Netmon device; hostname comes from _dns (PTR + custom overrides). Rows are deduped by IP — only the latest seen entry per IP within the window is returned. Permission: devices. Tag-scoping is NOT applied here — ARP is subnet-level, not device-level, so it doesn't have a tag anchor. Operators see the whole LAN regardless of tag scope. Examples: arp_table({}) // last 24h, no filter arp_table({hours: 1, search: "10.0.0"}) arp_table({search: "laptop"})

  ConnectorNo auth

• device_metric_summaryA

  Netmon (demo)A

  Day / week / month / all-time summary stats for a single device-tracker, by metric type. Multi-backend: pass `metric` to pick which upstream endpoint to hit. metric='latency' → wraps POST /api/latency/stats (icmpingId). Returns: dayAvgLatency, weekAvgLatency, monthAvgLatency, allTimeAvgLatency (ms); dayAvgLoss, weekAvgLoss, monthAvgLoss, allTimeAvgLoss (%); dayPingCount/weekPingCount/etc.; dayUptime/weekUptime/etc. (% successful pings); currentLatency, currentLoss, monitoringDuration (humanized). metric='disk' → wraps POST /api/disk/stats (diskId). Returns: dayGrowthKB, weekGrowthKB, monthGrowthKB, allTimeGrowthKB (negative = filling); estimatedFillTime (humanized projection from 7-day slope); plus current available/used measurements. **This is a fixed-window summary, not time-buckets.** Comparing day vs month tells the LLM 'is this metric degrading?'. For the raw samples underneath it, call device_get({id, hours: N, include_logs: true}) — the log rows are opt-in there because they are the expensive half of that response. Discovery: `target_id` is a TRACKER id, never a device id, and device_get is the only tool that hands one out. Both sit nested in its response and both survive its default summary shape — they are tracker identity, not log rows, so no flag is needed to see them: latency → device.ping.icmping_id. `ping` is a single object, not a list: a device has at most one icmping tracker, and its key is icmping_id, not id. disk → device.disks[].id, one entry per monitored volume (agent-collected or SNMP). Most devices carry none — an empty array means there is no disk tracker to summarize, not that the lookup failed. Port-stats has no equivalent endpoint upstream and is omitted; if one lands later, add a third metric backend. Permission: devices. Tag-scoped server-side via Devices::withUserTags() before stats are computed. Examples: device_metric_summary({metric: 'latency', target_id: 17}) device_metric_summary({metric: 'disk', target_id: 42})

  ConnectorNo auth

• speedtest_historyA

  Netmon (demo)A

  Recent WAN speedtest results — answers 'is the internet healthy?'. Wraps GET /api/getSpeedTestHistory. Returns rows ordered by timestamp desc. Each row carries the upstream's SpeedtestLog shape — typically {id, timestamp, download_mbps, upload_mbps, latency_ms, jitter_ms, server, ...}, but any new columns added on the Laravel side flow through automatically. The tool doesn't reshape the row contents — just filters by time window and limits the return. Lower priority than ping/traceroute/netflow for general 'internet slow' investigations, but the right tool when the user specifically asks about WAN throughput trends or recent speedtest runs. Filters (client-side): hours (1-720, default 168 = 7d), limit (1-100, default 25). The upstream endpoint returns the full history with no server-side cap — narrow with hours rather than fetching unbounded. Permission: tools. Example: speedtest_history({hours: 24})

  ConnectorNo auth

• search-memoA

  MemocoreA

  Search or recall memories from memocore (the user's persistent memory, also called "mc") — their own private memos and every project they belong to. Every search is HYBRID: `query` (a natural-language description of what you seek) drives meaning-based vector recall, `keywords` (the distinctive terms) drives keyword matching against the heavily-weighted `meta` cues, then title, preview and content; the two rankings are fused. Both are required — write them as two views of the SAME need, not two different questions — except in a DATED listing. `date_from` (optionally `date_to`) keeps only the memos that have a date in that window: alone, with NO query/keywords, it lists them nearest first — e.g. what is coming up in the next 3 days; with query + keywords it searches inside the window — e.g. only the calls. Each item then carries its `dates`. Results are LIGHTWEIGHT: each item shows only `title`, the short public `preview` summary, a `has_files` boolean, and where it lives — `project` and `company` as { id, name } and `tags` as [{ id, name }], so you can name the source and reuse the ids without a second lookup — but NOT the full `content`, the `meta` search cues, or the file list. An item with `shared: true` was reached through a company-wide share, not membership: it is READ-ONLY for you (no update/delete/tagging), and its project is deliberately unnamed — tell the user it is "shared with you" in that company. Fetch the full content, meta and attachment list for the ids you need with get-memos. Returns `items` in relevance order plus a `recommendation` — READ THE RECOMMENDATION before trusting anything: it states how solid the results actually are, because a search ALWAYS returns a full page of nearest memos even when the memory holds nothing on the subject. It tells you which items (if any) both sides agreed on and are genuinely on topic, which merely share a word, and when the honest answer is that nothing was found and you should answer from scratch. Narrow with `scope` (private / shared / a specific project), `tags` (only memos carrying ALL given tags) and `exclude_tags` (drop memos carrying ANY of them). With no `scope`/`company` the search spans EVERYTHING you can access (your private memos + every project you belong to, personal and company, + memos shared company-wide from company projects you are NOT in); when you are confident which project or company holds the answer, pass its `scope` or `company` to focus there instead (more precise). Use to recall what the user or their projects previously stored.

  ConnectorOAuth

• update-project-memoA

  MemocoreA

  Update a memo that lives in a SHARED project (visible to, and editable by, every member). Use this to actualize or merge into an existing memo instead of creating a near-duplicate. Only the provided fields change, and each REPLACES the old value wholesale — so to merge, fetch the current memo first (get-memos) and send the combined `content`, not just the new fact. Passing `tags` replaces the memo's tags (this project's tags only). Editing a shared memo can leak data into the project just like creating one, so before calling you MUST scan whatever you are writing (`content` / `title` / `meta`) for personal or sensitive data (private contacts, secrets, credentials, health/financial info). If any is present, proceed only on the user's explicit confirmation. `preview` is PUBLIC (shown in search results and exposable via public share links even outside the project), so it must never contain sensitive data. Set `privacy_reviewed` to true only once that check genuinely passes. For your own private memos use update-private-memo instead. If the memo's project has an `instruction` (search-projects reports `has_instruction: true`, the memo carries its project id), it has writing guidelines from its team: read them with get-project, follow them where they fit the user's request, and pass `instruction_reviewed: true`. A ROW of a table project (it carries `fields`) changes only through `fields`, never `content`: unlike the other fields, `fields` MERGES — send just the columns that change, `null` clears one. The response includes a `share_url` field: the public /m/ link if the memo is already shared, otherwise a hint. If the user wants a link, use that field (or follow the hint via set-memo-sharing); never build one from `id`. The response may carry a `recommendation` with `similar` (near-duplicate memos in this project — if any is truly the same, consolidate: merge into one, delete the extras with delete-memo, staying within this project) and `suggested_tags` (fitting project tags for this memo — add the relevant ones, especially if it has none yet).

  Connector

  Destructive

  OAuth

• get_categoriesA

  WEM Price CompareA

  Lists the six broad shopping categories WEM covers (electronics, fashion, beauty, home, sports, collectibles), each with example products, the shops WEM has read a price from in the last 14 days (busiest first, with how many shops there are in all) and the default currency (GBP). Use it to help a shopper narrow a vague request. It returns no prices, the category names are labels for the shopper, not filter values, and a shop on the list is not a promise that WEM holds a given product there: compare_offers says which shops WEM has for one product.

  ConnectorNo auth

• get_network_entity_infoA

  Netmon (demo)A

  Retrieves WHOIS, GeoIP and DNS information for a public IP address or hostname. A hostname is resolved to an IP for the GeoIP lookup (`resolved_ip`, when resolution succeeds); an IP gets a reverse DNS lookup (`hostname`, when a PTR exists). `whois` comes from whois.iana.org and nowhere else. For an address IANA returns the RIR referral record, so its `organisation` is the regional registry that administers the block (ARIN, RIPE, APNIC, LACNIC, AFRINIC) — NOT the ISP, hosting company or assignee. For a hostname it is the TLD registry, not the domain owner. Never report either as the operator; a `refer` or `whois` field only names the RIR's own whois server, which this tool does not query. `geoip` is the geolocation provider's response passed through verbatim, so the key set varies with provider tier and with whether the answer came from cache. Treat every field as optional — including `isProxy`, `asn` and `asnOrganization`, which may simply be absent. The whole `geoip` key is omitted for addresses that are not globally routable and when the lookup is unavailable. To judge hosting/datacenter versus residential or small-business ISP, reason from the evidence actually returned: - The `hostname` PTR pattern: a provider-branded label under a hosting or cloud domain reads as datacenter, whereas the address itself embedded in the name under a consumer ISP's domain reads as subscriber. A missing PTR is weak evidence in either direction. - `geoip.isProxy` when present: true points to a VPN, proxy or hosting exit. - `geoip.asnOrganization` (and `asn`) when present: a cloud, colocation or hosting provider points to a datacenter; an access or eyeball ISP points to residential. Label that classification as a heuristic and name the evidence you used for it. If no PTR came back and no ASN fields are present, say the evidence is insufficient rather than guessing.

  ConnectorNo auth

• eventlog_searchA

  Netmon (demo)A

  Search Windows Event Log entries ingested from Netmon agents. Wraps GET /api/eventlog/list (permission: logs); tag-scoped server-side. Severity is the raw Windows EventRecord.Level: 'logalways'=0 (what Security-channel audit events carry), 'critical'=1, 'error'=2, 'warning'=3, 'information'=4, 'verbose'=5 — pass names or ints. Note 0 is NOT Information. Window: `hours` (1-168, default 24) OR `start_time`+`end_time`. `limit` defaults to 50 (max 500). `total` in the response is the full match count — if it exceeds `limit`, narrow the window or add severity/source/message filters rather than bumping limit. Example: eventlog_search({severity: "error", hours: 4})

  ConnectorNo auth

• eve_searchA

  Netmon (demo)A

  Search Suricata EVE-format IDS events. Wraps GET /api/eve/list (permission: logs); tag-scoped server-side. Severity is Suricata-native: 1=high, 2=medium, 3=low/info — a 3-point scale, NOT syslog's 0-7. Takes names or ints: 'high'=1, 'medium'=2, 'low'/'info'/'informational'=3. Single value or an array, which may mix the two forms (e.g. ["high", 2]). IP filters: passing only src_ip or only dst_ip matches either side (OR); pass both to AND them together. `device_id` is a convenience — the controller resolves it to the device's IP and matches src_ip OR dst_ip (eve_log has no device_id column). Window: `hours` (1-168, default 24) OR `start_time`+`end_time`. `limit` defaults to 50 (max 500). `total` is the full match count — narrow via severity/IP/signature_id when truncated. Example: eve_search({severity: "high", hours: 2})

  ConnectorNo auth

• log_severity_summaryA

  Netmon (demo)A

  Count log events grouped by severity over a time window. One tool, three backends — pass `stream` to pick which. stream='syslog' → wraps /api/syslog/sevSum (severity 0-7, syslog scheme) stream='eventlog' → wraps /api/eventlog/sevSum (severity 0-5, Windows scheme) stream='eve' → wraps /api/eve/sevSum (severity 1-3, Suricata scheme) Use this for triage before pulling rows: 'how many criticals on host X today' returns one tight rollup instead of 1000 sample rows. Every result includes both the numeric key and a `label` so the LLM doesn't have to memorize three different scales. Window: `hours` (1-168, default 24) OR `start_time`+`end_time` (ISO-8601 UTC). Optional `device_id` narrows to one device — for eve, the controller translates this to a src_ip OR dst_ip match automatically (eve_log has no device_id column). ALL-ZERO IS NOT THE SAME AS CLEAN. A dead feed and a quiet network produce byte-identical answers here, so every response carries `meta.stream_health`: active — events landed inside your window; the counts mean what they say. stale — your window is empty, but the stream produced up to `last_event_at`, before it. The feed is alive and the empty window is real. silent — nothing in your window AND nothing in the 168h before it. Never report 'clean' from this state; `note` names the producer to check first. unknown — freshness could not be established. The zeros prove nothing. stale/silent come from re-asking the same stream over a window that strictly contains yours (one extra call, and only when every bucket is zero). No staleness threshold is guessed: `stale` means exactly 'the newest event predates the window you asked for', which on a 1-hour window is unremarkable. `checked_back_hours` and `events_before_window` say how much history the verdict rests on. Permission: logs. Tag-scoped server-side. Example: log_severity_summary({stream: 'syslog', hours: 1, device_id: 42})

  ConnectorNo auth

• netflow_raw_searchA

  Netmon (demo)A

  Search raw NetFlow records (per-flow, not aggregated). Wraps GET /api/netflow/list (permission: vne). HORIZON — read this before choosing a window: the raw table holds only about 15 MINUTES. cleanup_netflow (pg_cron, every 15 min) rolls flows into agg_netflow and DELETEs every netflow row whose end_time is older than 15 minutes. `hours` accepts 1-168, but no data older than that horizon exists to match, so a 24-hour request coming back empty is the expected outcome, not a fault. For anything beyond the last few minutes use netflow_search (the aggregated view). Within the horizon this is the drill-down: when netflow_search shows that 10.0.0.5 sent a lot of bytes to 8.8.8.8, this tool returns the actual flow rows, with the per-flow packet counts, scalar src_port and exact timing that the rollup discards. (vlan and the iface columns survive the rollup — netflow_search filters on those too.) IP / port filters: `src_ip`, `dst_ip`, `src_port` and `dst_port` are each STRICT equality on that one column and NEVER match the opposite side. Use the compound `ip` (src_ip OR dst_ip) or `port` (src_port OR dst_port) when you don't know which side the host or service was on — reaching for src_ip instead silently drops every flow where the host was the destination. Passing both src_ip and dst_ip ANDs them into a single direction. Window: `hours` (1-168, default 24) OR `start_time`+`end_time` (ISO-8601 UTC), matched by OVERLAP (start_time < end AND end_time > start) — any flow ACTIVE during the window matches, including flows straddling either edge and live flows whose end_time is padded a little into the future. `limit` defaults to 50 (max 500). 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_raw_search({ip: '10.0.0.5', dst_port: 443, hours: 1})

  ConnectorNo auth

• device_listA

  Netmon (demo)A

  List monitored devices. Wraps GET /api/devices (permission: devices); user's tag-scope is enforced server-side. Filters (all optional, combinable): - tag: tag slug, e.g. "snmp-up" or "switches". Slug is the stable lowercase-hyphen form; tag names with spaces won't match. - status: "up" or "down" (based on latest ping). - search: substring match on label + ip_address (case-insensitive). Relation flags (all default false — opt in only what you need to keep the response small): tags, alerts, ping, oids, walks, interfaces, ports, disks. Pagination: per_page defaults to 25 (max 200), page defaults to 1. meta.pagination.has_more tells you whether more pages exist. Example: device_list({tag: "snmp-up", per_page: 10})

  ConnectorNo auth

• device_getA

  Netmon (demo)A

  Fetch one device with its related state: tags, alerts, the ping / oid / interface / port / disk trackers configured on it, its SNMP walk trackers, and a netflow rollup. Wraps GET /api/device/{id} (permission: devices). **Bulk payloads are opt-in, and that is a change from how this tool used to behave.** It returned every log row every tracker collected in the window, inline: one 8-hour call on an ordinary host measured ~127 KB — 85 KB of oid log rows across 12 trackers, 35 KB for a single ping tracker's 479 samples — so pulling three hosts to "see the state" could spend 300 KB of context before any reasoning started. By default each tracker now returns its identity and latest value (which is what state questions need) plus `log_count`, the number of rows sitting in the window. include_logs:true puts the rows back. Pair it with max_log_rows (default 200 per tracker, newest kept) so one chatty tracker cannot swamp the response; a tracker that got cut carries logs_truncated:true next to the untrimmed log_count. When the question is "is this metric degrading?" rather than "what happened at 14:05?", device_metric_summary answers it from fixed-window stats and ships no rows at all. include_walk_data:true returns the stored SNMP walk payloads, omitted for the same reason: one configured walk tracker reaches ~72 KB of JSON on its own. Without the flag each walk row keeps id / oid / interval / timestamp plus walk_entries, the payload's top-level entry count. What stays unbounded: the tracker rows themselves. Both flags govern each tracker's history, never how many trackers come back — a switch with 190 monitored interfaces returns 190 interface rows in summary mode too. interfaces_search pages interface metadata across the fleet if that is the real question. Window: `hours` (1-168, default 8) or explicit start_time+end_time (ISO-8601 UTC). It scopes the netflow rollup and log_count as well as the rows themselves, so it still matters with include_logs off. The appliance monitors itself as the device holding ip_address 127.0.0.1 — resolve that one by IP (device_find), never by assuming id 1; the id is whatever the sequence allocated. Use device_list or device_find to locate an id first. Examples: device_get({id: 42}) — state only, the cheap default device_get({id: 42, hours: 24, include_logs: true, max_log_rows: 50})

  ConnectorNo auth

• agent_disk_usageA

  Netmon (demo)A

  Path-scoped folder-tree disk usage report from a Netmon agent — the 'D: drive is at 95%, what's eating it?' question. Wraps POST /api/getFolderUsageFromPath which RPCs into the agent's GETFOLDERUSAGEPATH command and returns the immediate-children size breakdown for the given path. Required parameters: device_id (the agent-enrolled device) and path (a Windows path on that device, e.g. "D:\\" or "C:\\Users"). Backslashes must be escaped in JSON strings — the LLM should pass "D:\\" not "D:\". Drill-down pattern: start at the drive root, identify the largest child, recurse with that child as the new path. The agent does not produce a recursive tree in one shot — that's a deliberate latency cap. Read-only by design. The agent's write paths (DELETEFILE, DELETEFOLDER, EXECUTEPS) are on the permanent deny-list at the top of tool_handler.cpp and not wrapped — even a future operator with the broadest possible PAT must not be able to drive deletions or shell exec from an LLM. Latency: BLOCKING; the upstream endpoint has a 120s timeout. Large folders may take real wall-clock time. Permission: devices. Windows-only — depends on agent enrollment (see CLAUDE.md agent enrollment section). Linux/macOS hosts have no agent-side equivalent of GETFOLDERUSAGEPATH. Example: agent_disk_usage({device_id: 42, path: "D:\\Users"})

  ConnectorNo auth