Skip to main content
Glama
Sign In
BrowserSolver MCP Server

BrowserSolver MCP Server

Official
by browsersolver
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

Website Rendering

website_rendering
Read-only

Render a public URL in a managed headless browser and return the HTML after client-side scripts finish, enabling collection of dynamic page content.

Instructions

Website Rendering. Run a managed browser session against a public URL and collect the HTML after client-side scripts finish. Prefer Crawler for static markup; escalate to WebUnlocker on approved hosts when challenges persist. Credit cost: 2 credits per call.

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": {
      "query": "<query>"
    },
    "name": "website_rendering"
  }
}

Input Schema

NameRequiredDescriptionDefault
queryYesPublic URL to load inside BrowserSolver's headless browser. Include http:// or https://.
fieldsNoComma-separated list of fields to keep in the response, with dot notation for nested fields (e.g. name,location.city). Does not change the credit cost.
timeoutNoHard ceiling, in seconds, for the render session. When reached, BrowserSolver returns whatever HTML is available. Default: 30.
wait_forNoCSS or XPath selector that must appear in the DOM before HTML is returned. The managed browser waits until the node exists (or until timeout).
block_adsNoSkip ad-network requests while the page renders. Default: false.
wait_in_secondsNoExtra pause, in seconds, after the page load event before BrowserSolver returns HTML. Helpful when widgets animate or hydrate late. Default: 0.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.3/5.0
Behavior4/5

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

Annotations already declare readOnlyHint, openWorldHint, and destructiveHint=false, so the safety profile is covered; the description adds a concrete cost model (2 credits per call) and the key behavioral trait that HTML is returned only after client-side scripts settle. It does not mention what happens on render failure or how the session terminates, which keeps it below a 5.

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?

Three dense sentences, front-loaded with the core action, then routing guidance, then cost. The opening 'Website Rendering.' merely echoes the title and is the only wasted fragment; everything after it earns its place.

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?

For a read-only, no-output-schema tool with fully documented parameters, the description covers purpose, escalation path, cost, and the returned artifact (HTML post-render). Only failure/empty-result behavior is unaddressed, a minor gap given a 6-parameter schema whose timeout semantics are already explained.

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%, with clear docs for query, fields, timeout, wait_for, block_ads, and wait_in_seconds, so the schema already does the heavy lifting. The description adds no parameter syntax, defaults, or interaction notes beyond that baseline, making 3 the correct score.

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 — 'run a managed browser session against a public URL and collect the HTML after client-side scripts finish' — which precisely captures the JavaScript-rendering behavior. It explicitly distinguishes itself from website_crawler ('static markup') and website_webunlocker ('when challenges persist'), so an agent can pick it apart from siblings without opening any 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?

It gives an explicit routing rule: prefer Crawler for static markup, escalate to WebUnlocker on approved hosts when challenges persist — implying this tool is the middle tier for JS-dependent pages. Both the alternative and the selecting condition are named, leaving nothing to inference.

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