wlanpi-mcp

Official

Overview Schema Source Related Servers Discussions Admin

capture_observe

Watch an active Wi-Fi capture in real time as a read-only subscriber, returning the current channel, security, and frame summary without altering the capture.

Instructions

Watch a streaming capture another application is already running, read-only.

Use this streaming subscriber to see what a capture started elsewhere (the WebUI, a lab controller, another agent) is receiving, without taking control of it. This never starts, reconfigures or stops a capture; the role in the result is always 'subscriber'. The result includes the owner's running config (channels, width, dwell, filter), so it is clear what the summary does and does not cover.

Returns the same dissected summary as capture_scan (an 'aps' table with full security detail, plus per-frame 'frames'/'frame_types' with addresses, radiotap and decoded results). The raw pcapng is also saved on the device and its path returned in 'pcap_path' (fetch it with fetch_pcap_file). Use list_capture_sessions first if you want to see what is running.

Single-radio caveat: the owner's channel hopping can fail on devices where the capture interface shares a radio with the managed wlan0, so an observed capture may cover fewer channels than its config lists.

Args: session_id: Session to attach to (from list_capture_sessions). interface: Instead of a session id, the monitor-mode capture interface ('wlanpiN', e.g. 'wlanpi0') whose capture to watch. duration_s: How long to listen, 1-60 seconds. The tool call blocks for this whole window. max_frames: Cap on per-frame records in 'frames'; the 'frame_types' counts are always exact. Set 0 for AP table and counts only, or a negative value for no cap (every frame).

Input Schema

TableJSON Schema

Name	Required	Description	Default
`interface`	No
`duration_s`	No
`max_frames`	No
`session_id`	No

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Sep 20, 2026

TDQS

A5/5.0

Behavior5/5

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

With no annotations, the description carries the full burden and does so thoroughly. It discloses read-only semantics, that the role is always 'subscriber', that it blocks for duration_s, that it includes the owner's config, and the raw pcapng path. The single-radio caveat is a valuable behavioral disclosure beyond basic function.

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?

The description is long but highly structured, with a purpose paragraph, an output/context paragraph, a caveat paragraph, and an Args list. Every sentence carries information; nothing is redundant. Front-loads the core purpose and scoping, then details parameters. Efficient for its depth.

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 and the absence of schema descriptions and annotations, the description is complete. It explains what it returns (aps table, frames, pcap_path), how to retrieve the pcap, prerequisites, and caveats. The presence of an output schema (though not shown) means the return format is covered, and the description adds the needed context for selecting and calling the tool.

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?

Schema description coverage is 0%, so the description must compensate, and it does. Each parameter is explained: session_id (session to attach), interface (monitor-mode interface alternative), duration_s (1-60, blocks), and max_frames (cap behavior including 0 and negative values). This adds meaning well beyond the schema's bare titles.

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 watches an existing streaming capture read-only, never starts/reconfigures/stops it, and differentiates from capture_scan by explicitly saying 'Returns the same dissected summary as capture_scan' while emphasizing the subscriber role. The purpose is specific and distinguishes from siblings like list_capture_sessions and capture_scan.

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 provides explicit usage guidance: 'Use list_capture_sessions first if you want to see what is running,' explains the session_id vs interface alternatives, and mentions the blocking duration. It also implies the alternative capture_scan for starting a new capture. The single-radio caveat adds important context for when to expect incomplete coverage.

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

Deploy Server