Skip to main content
Glama

AgentSearch Web Render

agentsearch_render
Read-onlyIdempotent

Render JavaScript-heavy pages in headless Chromium to capture fully loaded content as markdown, text, HTML, links, or screenshot when static extraction returns empty or partial results.

Instructions

Render one absolute http(s) URL in headless Chromium with AgentSearch Web Render, so JavaScript runs before content is captured, and return the backend response as pretty-printed JSON text (a non-JSON body is wrapped as {raw: text}). The response includes the final url, title, status_code, meta (render_ms, chars, truncated, js, lang …), warnings, error, and the rendered page body in each requested format: markdown (default), text, html, and/or links; plus an optional base64 screenshot. Use this when the page is a JavaScript-heavy app (SPA, client-rendered docs or dashboards) where agentsearch_extract returns empty or partial content; for static pages prefer agentsearch_extract (faster), and to find pages from a query use agentsearch_web_search. Paid tool: needs a wallet key (AGENTSEARCH_WALLET_PRIVATE_KEY or POCKET_PRIVATE_KEY) and then pays per call in USDC on Base over x402 through the Pocket Network Agentic Portal, never more than the per-call cap or AGENTSEARCH_MAX_TOTAL_ATOMIC per session (default $1.00); the result includes the payment receipt and the portal envelope {portal, data}, whose data is untrusted third-party content. With no wallet key it makes no network call and explains how to add one. If AGENTSEARCH_BASE_URL is set, it calls your self-hosted AgentSearch API instead (no payment). Note: the free tier serves search only; this tool needs a wallet key or a self-hosted API. Read-only: it loads the page like a browser visit and does not click, submit, or change anything, but it uses the network, has a hard backend deadline of about 4.2 s, and can hit rate limits (HTTP 429). Target-site failures (DNS, TLS, timeouts, bot walls, robots.txt) come back as a normal result with a non-null error object {code, message, retryable} and empty or partial content; invalid input or a disallowed URL (HTTP 400, e.g. UPSTREAM_REJECTED), rate limits (429) and service faults (5xx) are MCP errors with the code and whether it is retryable. Optional fields are forwarded unchanged to the API, which applies its own defaults and limits.

Input Schema

NameRequiredDescriptionDefault
urlYesAbsolute public http(s) URL to render (port 80/443).
blockNoResource types to block while rendering (default ["media","font"]).
formatsNoOutput formats to return (default ["markdown"]). Add "html" for the rendered DOM, "text" for plain text, "links" for anchors.
wait_msNoExtra fixed wait in ms after load (0–1500, default 0).
viewportNoBrowser viewport size.
full_pageNoCapture the full page height, clipped to 4000 px (default false).
max_charsNoCap on returned characters per format (1–100000, API default 20000).
screenshotNoAlso capture a screenshot, returned as base64 (default false).
wait_untilNoNavigation event to wait for before capture (default domcontentloaded).
screenshot_formatNoScreenshot encoding (default png; PNG over 1 MB is re-encoded as JPEG).
wait_for_selectorNoCSS selector to wait for (at most 1.5 s) before capture.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.3.6

TDQS

A4.4/5.0
Behavior5/5

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

The description adds tremendous value beyond annotations, detailing the hard deadline (4.2s), rate limit mechanics (HTTP 429), full read-only behavior, and specific error categorization (Target-site failures vs. MCP errors). Furthermore, it details the payment logistics (wallet requirements, per-call cost, self-hosting alternative).

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness2/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is excessively long and unstructured, conflating high-level usage guidance with deep technical constraints, billing policies, and detailed error handling. Its immense size makes it difficult to parse quickly.

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 inherent complexity of web rendering, payment infrastructure, and specific error conditions, the description is exceptionally complete. It leaves almost no ambiguity for an agent regarding prerequisites or operational constraints.

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 provides 100% coverage, which already documents all parameters. The description provides high-level context on the tool's operation but does not need to add specific semantic meaning to the individual parameters beyond what the comprehensive schema delivers.

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 clearly states the core action (render URL in headless Chromium) and distinguishes it from `agentsearch_extract` by highlighting its ability to run JavaScript and capture client-rendered content.

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?

It provides explicit usage context: use for JS-heavy apps (SPA, dashboards), prefer `agentsearch_extract` for static pages, and `agentsearch_web_search` for discovery. This is maximally instructive.

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