Ravenpost

Screenshot a website

capture_screenshot

Take screenshots of a web page — the workspace's own site, usually — with a headless browser, as a desktop (1440×900 at 2×) and/or a mobile (390×844 at 3×) capture, and save them to the media library as images: shots for create_video, or pictures for a post. Each device costs 2 credits; when the month's credits cover fewer devices than asked, it captures what they cover and says so, and once they are spent it is refused with the balance — tell the user, do not retry. The server fetches whatever public https address is given, so point it only at pages the user named; private and internal addresses are refused. fullPage captures the whole page (as a JPEG) rather than the first screen (PNG). Waits up to wait seconds (default 40) for the capture; a page that takes longer is finished with get_video.

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": {
      "url": "<url>"
    },
    "name": "capture_screenshot"
  }
}

Input Schema

Name	Required	Description
`url`	Yes	The page to capture, e.g. https://example.com/
`wait`	No	Seconds to wait for the capture (default 40)
`devices`	No	Which captures to take (default both)
`fullPage`	No	The whole page rather than the first screen (default false)
`workspaceId`	No	Which workspace to act in — an id from list_workspaces. Optional with a single workspace; REQUIRED once there are several, where guessing would mean posting one client's content to another client's accounts. Ask the user which one before publishing.

Output Schema

Name	Required	Description	Default
`ok`	No
`next`	No
`media`	No
`render`	No
`credits`	No
`ignored`	No
`posterUrl`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 1, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Goes well beyond annotations: discloses per-device cost (2 credits), partial-fulfillment behavior when credits cover fewer devices, refusal with balance when spent, SSRF-style rejection of private/internal addresses, and the JPEG-vs-PNG consequence of fullPage. Also warns that slow pages time out and should be handled with get_video instead.

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?

Front-loads what the tool does and keeps every clause functional — cost, refusal protocol, address restrictions, format implications, timeout fallback. It runs long as a single dense paragraph, and the workspace-selection warning lives only in the schema, but no sentence is idle.

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?

With an output schema present, the description needn't explain return values, and it still covers cost, partial results, refusal, security constraints, format behavior and timeouts. An agent has everything needed to call this correctly and to explain outcomes to the user.

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 the baseline is 3. The description nonetheless adds value the schema lacks: the resolutions and pixel ratios behind 'desktop' and 'mobile', the output format difference for fullPage (JPEG) vs first screen (PNG), and reinforces the wait default and its timeout escape hatch.

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 and resource ('Take screenshots of a web page with a headless browser'), specifies the output destination (media library as images) and the downstream consumers (create_video, a post). This distinguishes it from siblings like import_app_screenshots (app screenshots) and upload_media.

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 clear usage context: shots feed create_video or a post, and it explicitly says to point it only at pages the user named since the server fetches public https addresses. It also states the failure protocol ('tell the user, do not retry') when credits run out. It stops short of naming a substitute for capturing non-public or app-internal screens, which import_app_screenshots appears to cover.

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

All Ravenpost 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.