PageHub

Screenshot site

screenshot_site

Read-onlyIdempotent

Screenshot the DRAFT in a real browser (the preview, with the site's own JavaScript running) — the only way to see compiled CSS, theme, state-driven UI, scripts and responsive layout. Shoot sections with selector (full size, not scaled down), at the design width and at 390.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "screenshot_site"
  }
}

Input Schema

Name	Required	Description
`id`	No	Site id.
`path`	No	Page slug (omit for home).
`width`	No	320–1920 (default 1440).
`height`	No	480–2400 (default 900).
`fullPage`	No	Whole page; ignored with selector.
`selector`	No	CSS selector, e.g. "#check".

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 10, 2026
- changedInput schema / properties / id / description
```
Previous value: -"Site id. Pass it on every call."New value: +"Site id."
```
First observedSep 28, 2026

TDQS

A4.2/5.0

Behavior4/5

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

Annotations already cover read-only, idempotent, non-destructive profile, and the description adds genuinely new behavioral facts: rendering happens in a real browser with JS, it captures the draft/preview rather than the live site, and selector shots are rendered full size rather than scaled. It omits return shape (how many images, what format) and any rate/size limits.

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?

Two tight sentences with the core capability front-loaded and the practical shooting guidance second. The telemetry-style shorthand ('at 390', 'full size, not scaled down') is compact but slightly clipped for a reader unfamiliar with the workflow.

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

Completeness3/5

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

There is no output schema, so the description should say what comes back — a single image, an array, URLs, or inline data — and it does not. Everything else an agent needs (preview scope, browser rendering, selector behavior, width choice) is present, but the return-value gap is material for a tool whose whole output is a screenshot.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so baseline is 3, but the description adds real semantics: width should be the design width or 390, and selector captures a section at full size rather than scaled. That is meaning beyond the schema's numeric ranges and example selector.

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?

States a specific verb (screenshot) and resource (the DRAFT/preview of a site) and immediately qualifies the mechanism — a real browser with the site's own JavaScript running. The 'DRAFT' scope and the mention of compiled CSS/theme/scripts clearly separate it from drafting/editing siblings like update_page or outline_page.

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?

Gives a clear rationale for when to reach for it ('the only way to see compiled CSS, theme, state-driven UI, scripts and responsive layout') and prescribes shooting sections via selector at the design width and at 390. It does not name an alternative or state when not to use it, so it falls short of a 5.

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

All PageHub 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?