URLpipe

Capture console errors

capture_console_errors

Idempotent

Exposes POST /console. Loads the page in headless Chrome and returns what it reported through console.error and console.warn during load, plus uncaught exceptions and unhandled promise rejections (not console.log). 1 credit.

What you would open DevTools for: broken third-party scripts and client-side errors you cannot reproduce locally.

Input Schema

TableJSON Schema

Name	Required	Description
`url`	Yes	The page to fetch. Must be a public http(s) URL.
`sync`	No	Wait for the result and return it (default false). When false the call returns a token immediately and you collect the result with get_result.
`labels`	No	Your own keys to find this request by later, e.g. {"client": "acme"}: they come back with the result, in the webhook and in list_requests, which can filter by them. Up to 16 keys of up to 40 letters, digits, _ - or .; string values up to 256 characters.
`max_age`	No	How fresh a stored result must be to be reused, e.g. "2 hours" or "3 days". Default 7 days, maximum 30. A reused result is free. Pass "0" to force a fresh fetch.
`report_to`	No	Async only: a webhook URL to deliver the result to. Defaults to the project's configured endpoint, if it has one.
`project_id`	Yes	Which project this request belongs to. From list_projects.
`residential`	No	Fetch the page from a residential (home ISP) exit instead of a datacentre one. Costs a surcharge per page visit — see get_usage. Use it for sites that block datacentre traffic.
`page_options`	No	What to do to the page before anything is read off it. Applies to the result itself: removed ads and banners are gone from html, markdown and summaries too.
`idempotency_key`	No	Makes the call safe to retry: sending it again with the same key within 24 hours returns the first call's token and result instead of starting (and charging for) new work, even with max_age "0". Up to 255 printable ASCII characters; a UUID is ideal.

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedSep 25, 2026

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "$schema": "https://json-schema.org/draft/2020-12/schema",
+  "anyOf": [
+    {
+      "properties": {
+        "entries": {
+          "items": {
+            "properties": {
+              "text": {
+                "type": "string"
+              },
+              "type": {
+                "enum": [
+                  "error",
+                  "warning",
+                  "exception"
+                ],
+                "type": "string"
+              }
+            },
+            "type": "object"
+          },
+          "type": "array"
+        }
+      },
+      "required": [
+        "entries"
+      ],
+      "type": "object"
+    },
+    {
+      "properties": {
+        "labels": {
+          "type": "object"
+        },
+        "status": {
+          "const": "accepted",
+          "type": "string"
+        },
+        "token": {
+          "type": "string"
+        }
+      },
+      "required": [
+        "token",
+        "status"
+      ],
+      "type": "object"
+    }
+  ],
+  "type": "object"
+}

AddedSep 25, 2026

TDQS

A4.2/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=false, openWorldHint=true, idempotentHint=true, and destructiveHint=false. The description adds important behavior: it loads the page (a side effect), captures specific error types, explicitly excludes console.log, and mentions the 1-credit cost. It does not contradict the annotations and provides context beyond the structured hints, such as cost and the distinction from console.log.

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?

The description is exactly two sentences with no fluff. The core functionality is front-loaded in the first sentence, and the second sentence gives a practical use case. Every word earns its place, and it is not overly verbose despite the tool having 9 parameters.

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

Completeness4/5

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

An output schema exists, so return values are covered. The description explains what the tool does, what it captures, and when to use it. It does not explicitly mention the asynchronous behavior (sync=false returning a token) or the need to call get_result, but these are detailed in the parameter schema. Given the schema richness and the tool's complexity, the description is adequate and leaves the agent with enough to select and call 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 parameters are fully documented in the schema. The description adds no parameter-specific meaning beyond the schema, except the mention of '1 credit' which is cost-related but not tied to any parameter. The baseline of 3 applies because the schema carries the full parameter documentation and the description does not need to compensate.

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 states a specific verb and resource: it loads a page in headless Chrome and returns console.error/warn, uncaught exceptions, and unhandled promise rejections. It explicitly excludes console.log, which distinguishes it from generic page-fetch tools like fetch_html or scrape_url. The purpose is unambiguous and distinct from its 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 provides a clear usage scenario: 'What you would open DevTools for: broken third-party scripts and client-side errors you cannot reproduce locally.' This gives the agent a concrete context for when to invoke it. However, it does not explicitly name alternatives or state when not to use it, only implying the condition via the DevTools analogy.

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

All URLpipe tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?