Skip to content
NetsCLI

Interface coverage

One Rust core library sits under everything NetsCLI offers. Shared network behaviour belongs in the core; each surface exposes the parts that suit how it is used.

Three of the four are the same binary. netscli with a command is the CLI, netscli with no command opens the terminal UI, and netscli serve starts the MCP server. Installing the CLI installs all three. The desktop app is a separate download built on the same core.

That matters when reading the table below: a dash in the MCP column does not mean you need another install to get that capability, only that the MCP server does not expose it as a tool.

Capability Desktop app CLI TUI MCP
Discover hosts ✓ ✓ ✓ ✓
Scan TCP ports ✓ ✓ ✓ ✓
Scan UDP services ✓ ✓ ✓ ✓
Inspect host ✓ ✓ ✓ ✓
Sweep subnet ✓ ✓ ✓ ✓
Ping ✓ ✓ ✓ ✓
Trace route ✓ ✓ ✓ –
DNS lookup ✓ ✓ ✓ ✓
Reverse DNS ✓ ✓ ✓ –
mDNS discovery ✓ ✓ ✓ ✓
List interfaces ✓ ✓ ✓ ✓
Read the ARP table ✓ ✓ ✓ ✓
Change the ARP table ✓ ✓ ✓ –
Packet capture ✓ ✓ ✓ ✓
Structured output ✓ ✓ ✓ ✓
Result bundles ✓ – – –
First-run setup – ✓ – –
Diagnostics – ✓ – –
MCP service management – ✓ – –
Completions and man page – ✓ – –

✓ available here · – not offered here

  • Trace route has no MCP tool. Everything else it needs is in the core, so this is a gap rather than a decision.
  • Reverse DNS on the MCP server means asking dns_lookup for a PTR record, which works but wants the in-addr.arpa name rather than an address. The other three take an address directly.
  • Changing the ARP table needs administrator rights and edits machine state, which is not something to hand an agent. The desktop app offers clearing only; the CLI and TUI also add and delete single entries.
  • Result bundles are the desktop app’s own save format, for reopening a run later. The equivalent elsewhere is structured output: --json, --yaml, --csv and --md on the CLI, /export in the TUI, JSON-RPC results over MCP.
  • First-run setup (netscli setup) and diagnostics (netscli doctor) are two different commands and used to share a row here. Setup is an interactive wizard; doctor is a headless report that works on every build and is the way to find out what your build can do.
  • Packet capture needs a build compiled with the feature and the system capture library — Npcap on Windows, libpcap elsewhere. No default install has it: the desktop installers, the standard CLI assets and cargo install netscli are all built without it. Each release does publish separate -pcap CLI assets that have it compiled in. See Installation.
  • Structured output means something different on each surface, which is why it is one row rather than four: the desktop app exports files and result bundles, the CLI takes --json, --yaml, --csv and --md, the TUI exports a session with /export, and the MCP server returns JSON-RPC results.

Interactive network work: tabs, filtering, row selection, a details pane, history, exports, and local status indicators. It exposes the shared operations where a table or a details pane earns its place.

Shell maintenance — setup, doctor, completions, man pages, MCP service management — stays in the CLI, because none of it benefits from a window.

Every shared network operation, plus the workflows that only make sense at a prompt:

  • --json and --yaml on every operation, and --csv and --md on the ones that return a list.
  • netscli setup for the first-run wizard, netscli doctor for a headless capability report.
  • netscli serve to start the MCP server, and netscli mcp-service to manage it as a system service where that is supported.
  • netscli completions and netscli man.

The same operations, driven from a terminal with slash commands (/discover, /scan, /inspect, and the rest) rather than arguments. It favours readable summaries and keyboard navigation, and exports the session as Markdown or JSON with /export.

It is the same binary as the CLI, so anything installed for one is installed for the other.

Exposes the shared operations to AI-agent clients as MCP tools. Also the same binary.

Results are bounded before they reach a model: the full probe response is dropped, banners and packet summaries are truncated, and an oversized result is cut with a count of what was left out. A scanned host’s banner is bytes that host chose, and a model reads tool output as instructions.

Most NetsCLI operations work in the standard published builds. A few capabilities depend on how the app was packaged or what is installed on the machine:

  • Packet capture runs only on builds that include packet-capture support, and also needs Npcap on Windows or libpcap on Linux/macOS. On the CLI the pcap subcommand is absent from standard builds.
  • mDNS discovery is included in the published CLI, desktop app, and MCP server. Library consumers can still build netscli-core without the mdns feature if they need a leaner dependency set.
  • The desktop app keeps Packet Capture visible in builds without capture support — greyed, with an explanation of what it needs — rather than hiding it. A tool that vanishes leaves nowhere to explain why.
  • If a runtime dependency is missing, NetsCLI keeps the rest of the app usable and explains what to install for that feature.