Skip to main content
Glama

session_network

Read-only

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/nav); include_headers=true adds each request's outbound header set to its row (#97). Each row's nav is the navigation generation that issued it and the payload's top-level nav is the current one - a lower row nav belongs to an earlier (e.g. timed-out) navigation attempt (#101). 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.
include_headersNoAdd each request's outbound header set to its row (`headers` on the compact rows, `request_headers` on the `xhr` rows) — what the page's JS actually sent, signed customs like x-s/x-s-common included. Off by default: headers can carry tokens.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / include_headers
      Added value: +{
      +  "default": null,
      +  "description": "Add each request's outbound header set to its row (`headers` on the\ncompact rows, `request_headers` on the `xhr` rows) — what the page's\nJS actually sent, signed customs like x-s/x-s-common included. Off by\ndefault: headers can carry tokens.",
      +  "type": [
      +    "boolean",
      +    "null"
      +  ]
      +}
  2. Changed1 schema field changed
    • removedInput schema / title
      Removed value: -"SessionNetworkParams"
  3. Changed3 schema fields changed
    • 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"
      +  ]
      +}
  4. Changed1 schema field changed
    • changedInput schema / properties / filter / description
      Previous value: -"\"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. Omit to list every request as compact rows."New value: +"\"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."
  5. Added

TDQS

A4.3/5.0
Behavior5/5

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

Annotations only declare readOnlyHint=true, so the description carries most of the behavioral load and does so richly: default row shape (method/url/status/type/size/nav), via="network" vs via="dom" confirmation semantics, iframe kind handling, the nav generation meaning (plus the #97/#101 issue context), and the token warning around include_headers. This is substantial context beyond the annotations.

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

Conciseness3/5

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

Front-loads the purpose well, but the body is a dense run-on with many parentheticals and issue references, and the filter parameter is described twice (description and schema) almost verbatim. Most content is useful given the tool's complexity, but it is longer than it needs to be.

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?

With no output schema, the description compensates by describing the returned row structure, the merge of network/DOM candidates, and the headers addition. Combined with 100% parameter coverage and readOnlyHint, an agent has everything needed to call it 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?

Schema description coverage is 100%, so the schema already documents all six parameters. The description largely restates the filter and include_headers semantics already present in the schema; its only genuinely additive parameter context (nav generation meaning) concerns the output, not an input. Baseline 3 applies.

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?

Opens with a specific verb+resource ('Read the session's network request log') and immediately carves out distinct scope via the filter="media" behavior and the network/DOM merge semantics. An agent can distinguish it from siblings like session_console, session_storage, and fetch without opening the schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives a clear workflow prerequisite ('Navigate to the video page first, let it load, then call this') and explains when to prefer the media filter over the default listing. It does not name explicit alternative tools (e.g. fetch, session_console) or state when not to use it, so it falls just short of a 5.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.