Skip to main content
Glama
Sign In
pironjulien

nexus-browser

by pironjulien
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Local

browser_wait_network_idle

Read-onlyIdempotent

Waits until active Fetch/XHR network traffic settles after a click, form submission, or SPA navigation, so you can inspect the DOM only when loading finishes.

Instructions

Waits until network traffic settles (0 active Fetch/XHR request for idle_ms).

Call it after a click, a submission or a navigation in a single-page application (React, Angular, Vue, Google Cloud / Play Store consoles) before inspecting the DOM. timeout_ms: at most 115000 (bridge limit).

Input Schema

NameRequiredDescriptionDefault
tab_idYesYour tab's id (from browser_new_tab, or a tab adopted with browser_adopt_tab).
idle_msNo
timeout_msNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv2.31.6
    • changedOutput schema / (root)
      Previous value: -{
-  "properties": {
-    "result": {
-      "title": "Result",
-      "type": "string"
-    }
-  },
-  "required": [
-    "result"
-  ],
-  "title": "browser_wait_network_idleOutput",
-  "type": "object"
-}New value: +null
  2. First observedv0.1.0

TDQS

A4/5.0
Behavior4/5

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

Annotations already carry readOnly/idempotent/non-destructive, so the description's added value is the operational detail: exact idle definition and the 115000ms bridge ceiling. It doesn't say what the tool does on timeout (raise vs return a status), which is the one behavioral gap for a blocking wait.

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?

Two sentences, front-loaded with the idle condition and followed by the when-to-call guidance and the hard limit. The app examples add real disambiguation value rather than padding.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a blocking wait with no output schema and two undocumented parameters, the description should also cover timeout outcome and whether it resolves immediately when the network is already idle. Those gaps matter for an agent deciding whether to retry or inspect afterwards.

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

Parameters4/5

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

Schema coverage is only 33%, with only tab_id documented, but the description compensates: idle_ms is defined as the required quiet window with zero active Fetch/XHR, and timeout_ms gets a concrete upper bound. Defaults (300/8000) and timeout-side behavior are left to the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a precise verb and condition: wait until '0 active Fetch/XHR request for idle_ms'. That is far more specific than the name alone. It doesn't explicitly contrast with sibling waits (browser_wait_load, browser_wait_for), so an agent must still infer the boundary.

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 clear situational triggers: after a click, submission, or navigation in an SPA, and before inspecting the DOM, with concrete app examples. No exclusions or named alternatives (e.g. use browser_wait_load when a full page reload is expected), so it's a strong 4 rather than a 5.

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