URLpipe

Run a Lighthouse audit

run_lighthouse_audit

Idempotent

Exposes POST /lighthouse. Runs a real Google Lighthouse audit against the live page: performance, accessibility, best-practices and SEO scores plus Core Web Vitals. 2 credits — dearer than a page fetch because the audit runs in its own limited lane, so it also takes longer than anything else here.

It fetches the page itself rather than sharing a visit, so asking for it inside scrape_url costs two page visits, not one.

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.
`device`	No	Which profile to audit under. Default mobile.
`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.
`include_audits`	No	Include the full per-audit detail, not just scores and metrics. Much larger; default false.
`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 / anyOf

Previous value: -[
-  {
-    "properties": {
-      "audits": {
-        "type": "object"
-      },
-      "categories": {
-        "type": "object"
-      },
-      "device": {
-        "type": "string"
-      },
-      "fetchTime": {
-        "type": "string"
-      },
-      "metrics": {
-        "type": "object"
-      },
-      "url": {
-        "type": "string"
-      }
-    },
-    "type": "object"
-  },
-  {
-    "properties": {
-      "labels": {
-        "type": "object"
-      },
-      "status": {
-        "const": "accepted",
-        "type": "string"
-      },
-      "token": {
-        "type": "string"
-      }
-    },
-    "type": "object"
-  }
-]New value: +[
+  {
+    "properties": {
+      "audits": {
+        "type": "object"
+      },
+      "categories": {
+        "type": "object"
+      },
+      "device": {
+        "type": "string"
+      },
+      "fetchTime": {
+        "type": "string"
+      },
+      "metrics": {
+        "type": "object"
+      },
+      "url": {
+        "type": "string"
+      }
+    },
+    "type": "object"
+  },
+  {
+    "properties": {
+      "labels": {
+        "type": "object"
+      },
+      "status": {
+        "const": "accepted",
+        "type": "string"
+      },
+      "token": {
+        "type": "string"
+      }
+    },
+    "required": [
+      "token",
+      "status"
+    ],
+    "type": "object"
+  }
+]

AddedSep 25, 2026

TDQS

A4.4/5.0

Behavior5/5

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

The description goes well beyond annotations. It discloses that the tool makes a network request (openWorldHint true), is not read-only (readOnlyHint false) because it runs a computation and charges credits, supports idempotency (idempotentHint true) via idempotency_key, and is non-destructive (destructiveHint false). It adds unique behavior: it fetches the page independently, caches results (max_age), supports async delivery, and has a residential exit option. No contradiction with annotations.

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 two paragraphs, but every sentence carries useful information: purpose, cost, latency, fetch behavior, and a note about interaction with scrape_url. It is front-loaded with the core purpose. Slightly longer than necessary but justified by the tool's complexity.

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?

Given the tool's complexity (10 parameters, async modes, caching, cost), the description is thorough. It explains cost, caching, async vs sync, residential fetching, and idempotency. An output schema exists (not shown here), so return-value details are covered. Nothing an agent needs to invoke it correctly is missing.

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 input schema covers 100% of parameters with detailed descriptions, so the baseline is 3. The description does not add parameter-specific semantics beyond what the schema already provides; it adds context on cost and behavior, but that's not tied to individual parameters. It doesn't compensate for any gaps because there are none.

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 ('Runs a real Google Lighthouse audit') and resource ('against the live page'), and enumerates the exact outputs (performance, accessibility, best-practices, SEO scores, Core Web Vitals). This clearly distinguishes it from siblings like fetch_html or capture_screenshot, which serve different purposes.

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?

The description provides contextual guidance on when to use the tool: it mentions higher cost (2 credits) and longer runtime than other tools, and clarifies that it fetches the page itself, affecting cost when used inside scrape_url. However, it doesn't explicitly state 'use this when you need Lighthouse scores' or name alternative tools for comparison, so the guidance is implicit rather than prescriptive.

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?