"Deno" matching MCP tools:

• dero_docs_get_pageA

  DERO MCP ServerA

  Get a single bundled docs page by slug, with plain-text content and headings. When to call: AFTER dero_docs_search has returned a candidate slug, OR when you have a known slug from a prior citation. PREFER dero_docs_search first when you only have a topic in mind. Input Requirements (CRITICAL): - `slug` MUST be a non-empty doc slug relative to pages/ (e.g. `rpc-api/daemon-rpc-api`, `tutorials/first-app`, `dero-pay/quick-start`). - `product` is OPTIONAL but RECOMMENDED to disambiguate identical slugs across docs sites (`derod`, `tela`, `hologram`, `deropay`). - `offset` is OPTIONAL. Long pages (the Captain archive, deep RPC references) are returned in 60000-char chunks; if `content_truncated` is true in the response, call again with `offset: next_offset` to fetch the next chunk. Output: `{ product, slug, title, headings, content, content_offset, content_length, content_truncated, next_offset, canonical_url, last_updated, source_path }`. `content_length` is the total page size; `content_truncated` + `next_offset` signal whether to paginate.

  ConnectorNo auth

• recommend_docs_pathA

  DERO MCP ServerA

  Composite: take a natural-language intent, fan out parallel scoped searches across the bundled docs for all four DERO products (derod, tela, hologram, deropay), boost any product_hint matches by 1.5×, and return a ranked recommendation list with per-result rationale plus ready-to-cite related_docs. When to call: at the START of any "where do I read about X?" or "which docs cover Y?" investigation, BEFORE calling dero_docs_search directly. PREFER this over guessing the right product: this composite already runs all four products in parallel, dedupes overlap, surfaces the top heading per result as rationale, and gives you the top-2 citations pre-built. Pass product_hint when the user has already said e.g. "TELA" or "DeroPay" so that product's matches float to the top. Input Requirements: - `intent` is REQUIRED. Free-text description of what the user is trying to do (min 8 chars). Drop verbs and use product nouns like "deploy a TELA app" or "verify a DeroPay webhook signature" for best results. - `product_hint` is OPTIONAL. One of `derod | tela | hologram | deropay`. Multiplies hint-product scores by 1.5×. - `limit_per_product` is OPTIONAL (default 2, max 5). Cap per-product hits before merging. Output: `{ intent, product_hint, limit_per_product, recommended: [{ product, slug, title, canonical_url, score, boosted_score, rationale }], by_product: { derod | tela | hologram | deropay: { count, top_slug, top_score } }, related_docs: DeroCitation[] }`. `related_docs` is the top-2 picks pre-built as citations the agent can drop straight into a response. On zero matches across every product the composite returns a structured `_meta.error` with code `NO_DOCS_MATCH` and a hint to rephrase or drop the product_hint.

  ConnectorNo auth

• estimate_deploy_costA

  DERO MCP ServerA

  Composite: send a DVM-BASIC contract source to the daemon's gas estimator, then return the raw estimate alongside a plain-text breakdown (what each gas number means), the parsed contract surface, and curated DVM deploy docs as citations. When to call: BEFORE asking a wallet to broadcast a deploy transaction, OR when explaining the cost of a contract to a user. PREFER this over chaining dero_get_gas_estimate yourself: this composite already explains gascompute vs gasstorage in plain language, parses the SC source to show what functions the user is about to deploy (reusing extractScSurface from explain_smart_contract), and protects against fabricating a breakdown when the daemon reports 0/0 with a non-OK status. Input Requirements: - `sc` is REQUIRED. The full DVM-BASIC contract source — must contain at least one `Function ... End Function` block. A function body alone will fail with INVALID_INPUT. - `signer` is OPTIONAL. A dero1.../deto1... address that will sign the eventual deploy tx. The daemon uses it for fee context; omitting it still returns a meaningful estimate. - `include_breakdown` is OPTIONAL (default true). Set false when you only need the raw numbers (e.g. piping into a fee table). Output: `{ estimate: { gascompute, gasstorage, status }, breakdown: { compute_note, storage_note, total_units } | null, signer_used, include_breakdown, sc_surface: { functions, stringkeys, uint64keys, raw_code_length, function_count }, related_docs }`. `breakdown` is null when `include_breakdown=false` OR when the daemon returned 0/0 with a non-OK status (never fabricated). On DVM compile failure the composite returns a structured `_meta.error` with code `INVALID_INPUT` and the daemon's exact compile message in `_meta.error.raw`.

  ConnectorNo auth

• audit_chain_artifact_claimA

  DERO MCP ServerA

  Composite: audit a chain artifact (block topoheight, block hash, TX hash, and/or proof string) end-to-end. Returns a verdict (`cited_in_false_claim` | `clean`), the actual on-chain facts (block reward, TX acceptance status), an optional proof-string decode, a relayable narrative, and curated rebuttal docs citations. When to call: when the user asks "what's going on with DERO block X?" / "is this transaction the inflation-claim TX?" / "does this proof string come from a known false claim?" PREFER this over chaining `dero_get_block_header_by_topo_height` + `dero_get_transaction` + `dero_decode_proof_string` yourself: the composite already runs them in parallel, joins them against the flagged false-claim registry, and emits a single `verdict` field plus a narrative so the agent does not need to compose the rebuttal arc from scratch each time. Input Requirements (CRITICAL): - At least ONE of `topoheight`, `block_hash`, `tx_hash`, or `proof_string` MUST be provided. The composite throws `INVALID_INPUT` otherwise. - `topoheight` is OPTIONAL. Non-negative integer. - `block_hash` is OPTIONAL. 64 hex characters. - `tx_hash` is OPTIONAL. 64 hex characters. - `proof_string` is OPTIONAL. Full `deroproof…` / DERO bech32 string with HRP. - `include_forge_demo` is OPTIONAL (default false). When true AND `tx_hash` is provided, also forges a fresh demo proof for the same TX (via `dero_forge_demo_proof`) and embeds it under `forge_demo`. The demo amount auto-selects: a flagged artifact's pinned amount (e.g. -2.2M for the 2022 claim) > the cited `proof_string` V > -1 DERO. PREFER setting this true when the agent is fielding a "Verified ✓ means the chain minted coins, right?" question — the embedded forge IS the refutation. Output: `{ verdict, inputs, matched_artifacts[], context_note, chain_facts, proof_decode, forge_demo, narrative, related_docs, _diagnostics }`. `verdict` is `cited_in_false_claim` when any input matches the flagged-artifact registry, else `clean`. `chain_facts` is null when no chain-querying input was provided or all daemon calls failed; `proof_decode` is null when no `proof_string` was provided. `forge_demo` is null unless `include_forge_demo: true` was passed; on success it carries `{ skipped: false, forged_proof_string, target_amount, ring_slot, ring_size, ring_receiver_address, math, self_check, explorer_display_amount, demo_amount_source }` (the slim form — full citations stay at the top level). PREFER citing the returned `related_docs` verbatim in the agent response — they are the canonical rebuttal pages and have been validated against the bundled docs index by CI. Quote the `context_note` when verdict is `cited_in_false_claim` so the user understands why the artifact matters.

  ConnectorNo auth

• answer_whyA

  den — Korean AEC knowledge, curatedA

  건축·공간의 **왜·원리·득실**을 인과 경로로 설명한다. "왜 콘크리트에 양생이 필요한가", "왜 방수층에 보호몰탈을 까는가"처럼 이유를 묻는 질문에 쓴다. → 대신 쓸 것: 이미 아는 인과 **한 줄의 근거만** 확인하려면 evidence_for · 두 개념이 **이어지는지만** 보려면 path_between · **수치·조문**이 필요하면 k_snippets · 용어 **뜻**만 물으면 define. ★파라미터: depth 는 L1<L2<L3 순으로 경로를 넓게 본다(홉 상한 4). profile 은 depth 와 별개로 **탐색 예산**을 정한다 — direct=2홉/3경로, standard=기본, **deep 은 쿼터를 5회분 쓴다**(6홉/12경로). 둘 다 주면 profile 이 실제 예산을 정한다. as_of 는 YYYY-MM-DD. ★relevance=low 또는 no_path_reason 이면 den 이 그 경로를 갖고 있지 않다는 뜻이니 근거로 쓰지 않는다. 읽기 전용이고 외부를 부르지 않는다 — 적재된 정본만 본다.

  ConnectorNo auth

• path_betweenA

  den — Korean AEC knowledge, curatedA

  두 개념이 **어떻게 이어지는지** 확인한다. "단열과 결로는 어떻게 연결되나", "전단벽에서 층간변위까지"처럼 **출발·도착이 분명할 때** 쓴다. → 대신 쓸 것: 한 지점에서 **관계를 따라가며** 훑으려면 traverse · 공정 **전체 흐름**이면 scenario · **왜 그런지 설명**이 필요하면 answer_why · **한 연결의 근거**만이면 evidence_for. ★파라미터: a·b 는 문장이 아니라 **개념 이름/구**로 넣는다("결로" O, "왜 결로가 생기나" X). a 와 b 가 같으면 빈 결과다. scope 는 쉼표로 여러 축을 주면 **모두 만족**하는 경로만 남긴다 (climate=arid,epoch=ancient). **profile=deep 은 쿼터를 5회분 쓴다** — 먼저 기본으로 보고 빈손일 때만 올린다. ★경로가 없으면 만들어 내지 말고 연결이 확인되지 않는다고 말한다. 읽기 전용 · 외부 호출 없음.

  ConnectorNo auth

• scenarioA

  den — Korean AEC knowledge, curatedA

  공정 시나리오를 구성한다 — 관련 공정 노드를 모아 enables/requires 엣지로 위상정렬해 순서 있는 단계 흐름을 반환한다. '기초부터 3층까지 시공 순서', '가설공사 절차' 같은 **시퀀스·시나리오** 요청에 호출하라. → 대신 쓸 것: 단순 사실·수치는 k_snippets · **두 지점 사이**만 궁금하면 path_between · 한 노드의 **선후 이웃**만이면 traverse · 두 공법 **차이**는 compare. ★파라미터: max_nodes 는 **5~60 으로 잘린다**(기본 40). 올리면 넓게 모으지만 느슨한 노드가 섞여 ordering_coverage 가 떨어질 수 있다 — 먼저 기본으로 보고 gaps 를 본 뒤 올린다. 결정론(LLM 없음). ordering_coverage 가 낮거나 gaps 가 있으면 그래프에 순서 지식이 아직 없다는 정직한 신호 — 그 구간은 지어내지 말고 gaps 그대로 사용자에게 전하라. 읽기 전용 · 외부 호출 없음.

  ConnectorNo auth

• 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

• teapplix_set_order_ship_optionsA

  ActionShip by Teapplix DemoA

  Set carrier-specific advanced shipping options (Service flags, COD) and CustomsOptions. For the common sparse options — InsuranceType and Delivery.Signature / Delivery.Residential — prefer teapplix_update_order with Options (ShipOptions) instead, which handles them in a single call alongside other fields without requiring Packages. Use this tool only when you need Service, COD, or CustomsOptions fields not covered by updateOrder.Options. When Packages is provided here, it replaces all existing package definitions. [DEMO]

  ConnectorNo auth

• dero_daemon_pingA

  DERO MCP ServerA

  DERO daemon connectivity check via DERO.Ping. When to call: as the first step in any chain investigation to confirm the daemon is reachable. Call before dero_get_info if you are unsure whether DERO_DAEMON_URL is correctly configured. Input Requirements: none. Output: a "Pong" string when the daemon is healthy. On failure this tool returns a structured _meta.error with code RPC_UNREACHABLE and a retry hint.

  ConnectorNo auth

• explain_smart_contractA

  DERO MCP ServerA

  Composite: fetch a DERO smart contract (code + variables + balances) and return its function surface, a classification of the contract pattern (tela_index | tela_doc | token | registry | minimal | generic), a plain-language narrative, and curated DVM docs citations re-ordered so the most relevant page is first. TELA contracts (apps/files) are detected first and cite the TELA spec; for a deep TELA parse use tela_inspect. When to call: when the user wants to UNDERSTAND a smart contract — its functions, state shape, or which DVM concept to read about. PREFER this over chaining dero_get_sc with a docs lookup yourself: this composite already parses the DVM-BASIC source for function declarations, sorts stringkeys/uint64keys deterministically, and picks the right docs page from a heuristic so the agent does not have to learn DVM-BASIC syntax to summarize a contract. Input Requirements: - `scid` is REQUIRED. Must be 64 hex chars (the smart contract id). Use `0000…0001` for the on-chain name registry as a known-good example. - `topoheight` is OPTIONAL. Provide to inspect the contract at a specific topo height; omit for latest tip. Output: `{ scid, topoheight, kind, surface: { functions[], stringkeys[], uint64keys[], balances }, narrative, raw_code_length, has_code, related_docs }`. `kind` is one of `tela_index | tela_doc | token | registry | minimal | generic`. `surface.functions` items are `{ name, args, returns }`. `has_code` is false when the SCID is unknown or has no on-chain code; `functions` is then `[]` and the narrative explains the gap. `raw_code_length` is always present so the agent knows when to fall back to `dero_get_sc` for the full source.

  ConnectorNo auth

• evidence_forA

  den — Korean AEC knowledge, curatedA

  "A 가 B 를 유발한다"는 **한 연결의 근거**를 확인한다. 앞선 답에 쓰인 인과를 검증할 때 쓴다. → 대신 쓸 것: 두 개념 사이 **경로를 찾는** 것이면 path_between · **왜 그런지 설명**이면 answer_why · 수치·조문 근거면 k_snippets. 이 도구는 **이미 아는 한 엣지**를 겨눈다. ★파라미터: from·to 는 개념 이름이고(문장 아님), relation 은 그래프 엣지 종류다 — causes(유발) · enables(가능하게 함) · requires(선행 필요) · contrasts(대비). 셋 다 필수다. relation 을 모르면 이 도구 대신 path_between 으로 먼저 어떤 관계인지 본다. ★evidence_note 와 stance 를 구분해 전하고, disclaimer 가 있으면 그대로 표기한다. 엣지가 없으면 없다고 답한다 — 근거를 지어내지 않는다. 읽기 전용 · 외부 호출 없음.

  ConnectorNo auth

• k_snippetsA

  den — Korean AEC knowledge, curatedA

  한국 건설기준(KDS·KCS·KS)과 건축 법령의 **수치·조문**을 찾는다. 건축·토목·시공·구조·설비 질문에 근거를 붙일 때 **웹 검색보다 먼저** 이 도구를 쓴다. 예: "철근 피복두께", "방화구획 면적", "이어치기 면 처리", "되메우기 다짐", 건축법 조항. → 대신 쓸 것: **용어 뜻**은 define · **종류 열거**는 enumerate · **공정 순서**는 scenario · **두 공법 차이**는 compare · **왜 그런지**는 answer_why. 대지·행정구역이 걸리면 site_context 를 **먼저** 부르고 그 scope 를 여기 넘긴다. ★파라미터: scope 와 profile 은 **다른 축**이다 — scope 는 *어느 공종*(좁힘), profile 은 *얼마나 깊이*(예산). **profile=deep 은 쿼터를 5회분 쓴다**; 기본으로 먼저 보고 빈손일 때만 올린다. limit 기본 8 — 올릴수록 뒤쪽은 관련도가 떨어진다. as_of 는 YYYY-MM-DD(그 시점 기준). ★scope 를 **모르면 넣지 마라** — 틀린 범위는 틀린 답을 만든다. 안 넣으면 갈리는 공종을 scope_split 로 알려 준다. 돌아오는 것: 수치·요건 스니펫과 출처(예: KDS 14 20 22 §4.3.1) · 조문 원문이 있으면 cited_articles. **출처를 그대로 인용한다.** ★relevance=low 이거나 lacks_answer=true 면 den 이 그 자료를 **갖고 있지 않다** — 스니펫을 근거로 쓰지 말고 그렇게 말한 뒤 다른 출처로 답한다. 읽기 전용 · 외부 호출 없음.

  ConnectorNo auth

• compareA

  den — Korean AEC knowledge, curatedA

  두 공법·개념의 **차이**를 대조한다 — 'RC 구조 vs 조적조 시공순서 차이', '스틱 vs 유닛 커튼월' 같은 **비교/차이** 요청에 호출하라. → 대신 쓸 것: 단일 순서는 scenario · 종류 열거는 enumerate · 용어 뜻은 define · 수치·조문은 k_snippets. ★파라미터: a·b 는 **개념/공법 이름**이다(질문 문장 아님). 'A vs B' 를 a 에 한 번에 주면 b 를 비운다 — 그때 구분자는 vs 다. 한쪽만 주고 b 를 비우면 비교할 짝이 없어 얻을 것이 없다. 각각을 결정론 구성해 A/B 시퀀스, A에만/B에만 있는 단계, 공유 단계, contrasts 엣지를 반환한다. LLM 없음. a_coverage/b_coverage 가 낮으면 그쪽 지식이 얇다는 정직한 신호 — 지어내지 말고 gaps 그대로 전하라. 읽기 전용 · 외부 호출 없음.

  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