Skip to main content
Glama
Sign In
adhistory-mcp

adhistory-mcp

by OBrandon
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

Website screenshot

website_screenshot
Read-onlyIdempotent

Capture public web pages as PNG or JPEG screenshots and return hosted image URLs, with full-page or viewport capture, device sizing, CSS selector targeting, and cookie-banner hiding.

Instructions

Take a screenshot of public web pages and return an image URL for each (PNG or JPEG, hosted in the user's Apify storage). Each item: url, final URL, HTTP status, page title, screenshotUrl, size and viewport. Cookie banners and ads are hidden by default. Pages behind a login are not supported. Cost: $1.00 per 1,000 screenshots ($0.001 each) on the user's Apify account. Latency: usually 10-30 s per page.

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": {
      "urls": "<urls>"
    },
    "name": "website_screenshot"
  }
}

Input Schema

NameRequiredDescriptionDefault
urlsYesPublic page URLs.
widthNoOptional viewport width override.
deviceNoWindow size and browser type.desktop
heightNoOptional viewport height override.
selectorNoOptional CSS selector to capture one element, e.g. '#pricing'.
dark_modeNoAsk the page for its dark color scheme.
full_pageNoWhole scrollable page (up to 16,000 px) or just the first screen.
image_formatNoPNG is sharper, JPEG is smaller.png
delay_secondsNoExtra wait for animations and late content.

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.4.0

TDQS

A4.5/5.0
Behavior5/5

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

Annotations already declare readOnly, idempotent, non-destructive open-world behavior, and the description adds substantial context beyond that: cookie banners and ads are hidden by default, output lives in the user's Apify storage, and both cost and latency are quantified. It also discloses a real operational constraint (login-protected pages fail) and a hard limit (full page up to 16,000 px), which are exactly the traits an agent cannot infer from the schema.

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

Conciseness5/5

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

Five compact sentences, front-loaded with capability and output, then constraints, then cost and latency. Every sentence carries distinct information — none restates the tool name or the schema.

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?

Output schema exists, so return values need not be explained, yet the description still names the item fields an agent will need to chain on (screenshotUrl, final URL, status). Combined with the cost, latency, privacy and size-limit disclosures, the definition is sufficient for correct invocation of a 9-parameter, pay-per-use, open-world tool.

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%, so every parameter already documents itself, including the format tradeoff ('PNG is sharper, JPEG is smaller') and the selector example. The description confirms the PNG/JPEG output choice and mentions viewport in the returned items, but adds no parameter-level meaning beyond the schema, so baseline 3 applies.

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 a screenshot of public web pages') plus the concrete output ('return an image URL for each, PNG or JPEG'). The scope qualifier 'public' and the explicit 'Pages behind a login are not supported' make the boundary of the capability unambiguous to an agent, which matters because no sibling tool covers anything similar.

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 and an explicit exclusion ('Pages behind a login are not supported'), plus decision-relevant economics (cost per 1,000 screenshots) and latency (10-30 s per page) an agent can weigh before calling. What is missing is any named alternative or fallback for the unsupported login case, so guidance stops short of full routing advice.

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