Skip to main content
Glama
yinnho

AginxBrowser

by yinnho
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Rust

session_network

Read-only

Inspect a session's network request log. Use filter=media to extract real video/stream URLs (HLS, MP4, DASH) actually requested by the page, avoiding decoy links in HTML.

Instructions

Read the session's network request log. filter="media" extracts playback/stream URLs (m3u8/HLS, mp4, dash, flv...) actually requested by the page's player at runtime - the reliable way to get a real video link, since links embedded in page HTML are often decoys. Media elements and player iframes the engine never fetches (video/audio/source/iframe src) are merged in as candidates: via="network" entries are confirmed requests, via="dom" entries are candidates carrying their tag (iframes = kind "iframe", navigate into them to sniff). Default returns every request as compact rows (method/url/status/type/size). Navigate to the video page first, let it load, then call this.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
filterNo"media" extracts playback/stream links (m3u8/HLS, mp4, dash, ...) from the requests the page actually issued - the reliable way to get a real video link, since URLs embedded in page HTML are often decoys. Media elements and player iframes the engine never fetches (video/audio/source src, iframe src) are merged in as candidates: entries carry via="network" (confirmed requests) or via="dom" (candidates, with their tag; iframes surface as kind "iframe" - player pages to navigate or sniff inside, not playable URLs). Omit to list every request as compact rows.
session_idYesSession ID
url_containsNoNarrow the `xhr` array to URLs containing this substring.
body_max_charsNoPer-body character cap for the `xhr` array (default 4000).
include_bodiesNoAdd an `xhr` array of background API responses (the page's own fetch/XHR traffic with retained bodies) alongside the request rows — the page's API face is often the cleanest structured read of its data.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.5.1
    • removedInput schema / title
      Removed value: -"SessionNetworkParams"
  2. Changed3 schema fields changedv0.3.3-rc1
    • addedInput schema / properties / body_max_chars
      Added value: +{
+  "default": null,
+  "description": "Per-body character cap for the `xhr` array (default 4000).",
+  "format": "uint",
+  "minimum": 0,
+  "type": [
+    "integer",
+    "null"
+  ]
+}
    • addedInput schema / properties / include_bodies
      Added value: +{
+  "default": null,
+  "description": "Add an `xhr` array of background API responses (the page's own fetch/XHR\ntraffic with retained bodies) alongside the request rows — the page's\nAPI face is often the cleanest structured read of its data.",
+  "type": [
+    "boolean",
+    "null"
+  ]
+}
    • addedInput schema / properties / url_contains
      Added value: +{
+  "default": null,
+  "description": "Narrow the `xhr` array to URLs containing this substring.",
+  "type": [
+    "string",
+    "null"
+  ]
+}
  3. First observed

TDQS

A4.6/5.0
Behavior5/5

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

Annotations declare readOnlyHint=true, and the description adds substantial behavioral detail: it explains the via='network' vs. via='dom' distinction, merges media elements and iframes as candidates, describes the default output format (compact rows with method/url/status/type/size), and clarifies that iframes are navigable rather than playable. This goes beyond annotations to disclose runtime behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is dense but organized, leading with the core purpose and then layering details about the filter, candidates, and output format. It repeats some of the filter explanation from the schema but remains readable. It could be slightly more concise without losing nuance, but it's efficient.

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?

The description covers the primary use case, prerequisite action, output structure, edge cases (iframe candidates), and parameter behavior. Since there is no output schema, it adequately describes the returned fields (via, kind, rows). This is complete for an agent to call correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema has 100% description coverage, so all parameters are documented there. The description adds contextual explanation (e.g., why filter='media' is reliable) but doesn't introduce new parameter meaning beyond what the schema already provides. Per the baseline for full schema coverage, this is a 3.

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 verb and resource: 'Read the session's network request log.' It explains the filter parameter's purpose (extract media URLs) and differentiates from page HTML links as decoys. This distinguishes it from siblings like session_navigate or fetch, which operate differently.

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?

The description provides explicit usage context: 'Navigate to the video page first, let it load, then call this.' It also explains when to use filter='media' vs. the default, and mentions the reliability advantage over embedded links. This effectively guides when to choose this tool over alternatives.

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

Deploy Server

Other Tools