Skip to main content
Glama
Sign In
Computer Use

Computer Use

by munimtechnologies
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Rust
Local

List page errors

browser_page_errors
Read-onlyIdempotent

Lists uncaught JavaScript exceptions, console errors, and failed requests for a tab to diagnose empty, broken, or unresponsive pages before reloading or assuming sign-in issues.

Instructions

List the problems the page in one of the agent's tabs has reported: uncaught JavaScript exceptions and console errors the page has logged since it loaded (Chrome keeps a limited number), and requests that failed since the agent attached to the tab (network errors and HTTP status 400 or above), oldest first, with how long ago each happened. Use it when a page is empty, broken or ignores an action, before navigating again or assuming a sign-in problem. The reply says when watching for failed requests began; ones Chrome still held from before are marked as earlier. Exceptions and console errors are read from what Chrome keeps for the page during this call only, so the page is not watched for them in between. The latest 50 are listed. URLs are shown without query strings, fragments or credentials, and request headers, cookies and bodies are never read. Read-only: it does not reload, navigate or show the tab.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "tab_id": "<tab_id>"
    },
    "name": "browser_page_errors"
  }
}

Input Schema

NameRequiredDescriptionDefault
tab_idYestab_id of one of the agent's tabs, from browser_open_tab or browser_list_tabs
session_idNoStable task or thread ID. Pass the same value on every browser call for this task. Different IDs isolate tabs and cleanup within one MCP process. Omit for the default process session.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.13.0

TDQS

A4.4/5.0
Behavior5/5

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

Goes well beyond the readOnly/idempotent annotations: it discloses ordering (oldest first), the 50-item cap, retention behavior in Chrome, that exceptions are only captured during the call rather than watched between calls, that the response marks when request-watching began and flags pre-existing requests, and that URLs are stripped of query strings, fragments, and credentials.

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?

Front-loads the definition and then layers caveats and privacy guarantees, with essentially no filler. The tradeoff is that the middle sentences are dense run-ons about retention and the 50-item cap that could be broken up or tightened for faster scanning.

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?

Fully covers the semantics an agent would need: what is captured, what is not, ordering, quantity limits, timestamps, and redaction. Since no output schema exists, the description carries that burden itself and does so completely.

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 two parameters are fully documented in the schema, so the description does not need to re-explain them. It adds only the implicit tie between tab_id and 'one of the agent's tabs,' with no additional formatting or constraint detail, which matches the baseline for complete schema coverage.

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: lists uncaught JavaScript exceptions, console errors, and failed requests for a page in one of the agent's tabs. It enumerates the three error categories and ties them to the tab scope, which makes it clearly distinct from siblings like browser_read or browser_snapshot.

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 explicit triggering conditions: when a page is empty, broken, or ignores an action, and before navigating again or assuming a sign-in problem. It does not name specific alternative tools (e.g., browser_snapshot vs browser_read) or say when not to use it, which keeps it 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.

Deploy Server

Other Tools