Render any public URL in a real browser (Chromium). Returns markdown text, a screenshot URL, and a human-checkable evidence page URL. $0.005 per call. No signup, no API key. x402 wallet required. Pass fullPage:true for the entire scrollable page (same price).
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | Public https URL to render | |
| fullPage | No | Capture entire scrollable page (same $0.005) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully carries behavioral disclosure: it runs in a real Chromium browser, returns markdown plus screenshot/evidence URLs, costs $0.005, requires an x402 wallet, and explains fullPage pricing. This is unusually thorough for a simple render tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded: it opens with what the tool does, then output/evidence, pricing/auth, and the fullPage hint. Every clause adds operational information an agent needs before calling.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, so describing the three return artifacts (markdown, screenshot URL, evidence page URL) is essential and included. With only two parameters and no nested objects, the description covers invocation, cost, auth, and behavior sufficiently for correct selection and use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents both parameters. The description adds 'any public URL' and the same-price note for fullPage, but no parameter-specific meaning beyond the schema, matching the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States an unambiguous verb+resource: render any public URL in a real Chromium browser, and lists concrete outputs (markdown, screenshot URL, evidence page URL). The scope 'any public URL' clearly separates it from the website-management/domain sibling tools such as publish_website or preview_status.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The use case is implied: use this when you need a rendered, evidence-backed view of a public URL, and it gives relevant prerequisites (x402 wallet, public URL). However, it never explicitly compares against siblings such as inspect or scan, nor states any exclusions or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
claim and publish_website both describe taking a website live, creating real ambiguity about which tool to call once a preview is ready. scan and inspect also overlap in that both check for unsafe files, but the descriptions clearly separate free scanning from paid preview deployment. Other tools are distinct enough given their detailed descriptions.
The set mixes single-word verbs (claim, edit, inspect, renew, scan) with verb_noun pairs (connect_custom_hostname, publish_website, render_page, upload_url), and preview_status reads more like a status endpoint than an action. However, all names are snake_case and mostly descriptive, making the inconsistency moderate rather than chaotic.
10 tools is within the reasonable range for a publishing workflow, and each lifecycle step from upload through preview, claim, renew, edit, and custom hostname is represented. render_page feels somewhat tangential to the site-hosting domain, but it does not significantly bloat the set.
The main publish workflow is well covered: upload, security scan, preview, status, claim, renew, edit, and custom hostname. Obvious lifecycle gaps remain, such as no way to list live sites, read remaining lease duration for a live site, or delete/unpublish a site. There is also no dedicated 'get live URL' tool, though claim likely returns it.