Skip to main content
Glama
Gwakko

agent-in-browser

by Gwakko
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Go
Local

network_requests

Read-only

List network requests made by a browser tab since attachment to verify API calls fired, find 4xx/5xx errors, and see what a page loads. Filter by URL pattern or failures only.

Instructions

Read-only: list network requests made by the tab since agent-in-browser attached, one line per request with method, HTTP status (or FAILED reason / pending), resource type and URL. Use it to check that an API call fired, find 4xx/5xx errors or see what a page loads. Request and response bodies are not included. Requests made before attaching are missed, so navigate with action=reload first. For script errors use console_messages.

Input Schema

NameRequiredDescriptionDefault
tabNoTab id from tabs_list. Defaults to the current tab.
clearNoEmpty the request buffer after reading so the next call only shows new requests.
limitNoReturn only the last N matching requests (default 100).
patternNoRegular expression the request URL must match, e.g. "/api/".
failed_onlyNoOnly network failures and responses with HTTP status 400 or above.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changedv0.1.2
    • changedInput schema / properties / clear / description
      Previous value: -"Clear the buffer after reading."New value: +"Empty the request buffer after reading so the next call only shows new requests."
    • changedInput schema / properties / failed_only / description
      Previous value: -"Only failed requests and HTTP status >= 400."New value: +"Only network failures and responses with HTTP status 400 or above."
    • changedInput schema / properties / limit / description
      Previous value: -"Last N entries (default 100)."New value: +"Return only the last N matching requests (default 100)."
    • changedInput schema / properties / pattern / description
      Previous value: -"Regex the URL must match."New value: +"Regular expression the request URL must match, e.g. \"/api/\"."
  2. First observedv0.1.1

TDQS

A4.7/5.0
Behavior5/5

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

Annotations declare readOnlyHint=true and the description's 'Read-only:' opener is consistent with that. Beyond annotations it discloses the retention window (only requests since attach), the absence of request/response bodies, the per-request output shape including FAILED/pending states, and the workaround (reload) to capture earlier traffic – context an agent cannot infer from the schema.

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?

Front-loaded with 'Read-only' and the core operation, then use cases, then caveats, then the sibling redirect. Four sentences with no filler; each carries distinct information (output shape, purpose, limitation, alternative).

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?

No output schema exists, but the description compensates by describing the returned line format and the FAILED/pending states. With annotations covering safety and a fully documented schema, nothing material is missing for correct invocation.

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%, and every parameter (tab, clear, limit, pattern, failed_only) is already documented with an example in the schema. The description adds no additional semantics for these parameters beyond what is structured, so the 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?

States a specific verb and resource ('list network requests made by the tab') plus the scope constraint ('since agent-in-browser attached') and the exact line format returned. It also explicitly names the sibling it is not for ('For script errors use console_messages'), so an agent can distinguish it from console_messages and get_text without opening a schema.

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?

Gives concrete when-to-use cases (verify an API call fired, find 4xx/5xx, see what a page loads) and explicit exclusions (response bodies not included, use console_messages for script errors). It also names the prerequisite failure mode and the remedy: requests before attaching are missed, so navigate with action=reload first.

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