Skip to main content
Glama

Aginx Browser

by net.aginx

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). 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

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. 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."
  2. Added

TDQS

A4.4/5.0
Behavior5/5

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

Despite readOnlyHint being the only annotation, the description discloses substantial runtime behavior: via="network" are confirmed requests, via="dom" are un-fetched candidates, iframes are kind "iframe" and should be navigated into, and the default output is compact rows. This goes far beyond the annotation and tells the agent exactly what to expect.

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 front-loaded with the core purpose and each sentence carries operational value. It is fairly long and largely duplicates the filter schema's wording, which keeps it from earning a 5.

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?

There is no output schema, so the description carries the burden of explaining return shape, and it does: compact rows with method/url/status/type/size plus via tags. It also covers the prerequisite navigation step and the iframe follow-up action, so an agent has enough context to use the tool 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 baseline is 3. The tool description's filter semantics mirror what the schema already documents; it adds no new parameter-level meaning. The session_id parameter remains only 'Session ID' in both places.

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 opens with a specific verb and resource: 'Read the session's network request log.' It then clearly details the two modes (default rows and filter="media") and distinguishes network-confirmed entries from DOM candidates. This makes the tool's purpose unmistakable and unique among the session_* siblings.

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?

It explicitly says to navigate to the video page, let it load, then call, and explains when filter="media" is the reliable choice because HTML-embedded links are often decoys. It doesn't name sibling tools as alternatives or state an explicit when-not-to-use, but the context is otherwise clear.

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

All Aginx Browser toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A3.8/5.0
Disambiguation4/5

Most tools have distinct purposes, but there's overlap between session_click/click and session_eval/eval. Descriptions clarify that session_* tools operate on persistent sessions while the others are one-off, so ambiguity is low.

Naming Consistency4/5

The session_* prefix is consistently used for session-related tools (17 of 23), while the remaining tools (cache, click, download, eval, fetch, search) are single-word lowercase verbs. This is a clear pattern, though not strictly verb_noun.

Tool Count4/5

23 tools is above the typical 3-15 range but reasonable for a browser automation server that needs both one-off and session-based operations. The count is justified by the breadth of features, though it's slightly heavy.

Completeness5/5

The surface covers all major browser automation needs: navigation, clicking, typing, scrolling, screenshot, state inspection, console/network logs, cookies/storage management, JavaScript eval, waiting, and even session export. No obvious gaps for the stated purpose.

Resources