Skip to main content
Glama

Wayback Machine Snapshot Finder: Archive Dates & URLs

wayback_snapshot_finder
Read-only

Find historical Internet Archive Wayback Machine snapshots for pages or whole domains to cite dead links, prove what a page said on a date, or date a site's first appearance.

Instructions

Find Internet Archive Wayback Machine snapshots for pages or whole domains through the official CDX API: capture timestamps, direct archive URLs, HTTP status, MIME type, content digest, and first/last-seen dates. Unlike website_change_monitor (diffs the live page on a schedule) and reference_checker (verifies scholarly citations), this looks up historical archived copies. Use when you need to cite or recover a dead link, prove what a page said on a date, date when a site or page first appeared, or list a domain's archived URLs. Do not use to fetch or diff live pages (use website_change_monitor) or to download full archived page content. Parameters: urls with matchType exact|domain|prefix, or domains (always domain match); from/to bound the date range (YYYY or YYYYMMDD); closestTo sorts by nearness to one date; collapseDigest (default true) keeps one row per unique content; filterStatus=200 drops redirects and errors; maxResultsPerUrl applies before maxResults, which caps billed snapshots (hard max 5000); includeFirstLast adds extra CDX probes and can add latency. Empty or failed lookups are free; the Archive's CDX API can be slow, so allow up to a minute or more. Returns per item: agentSummary, url, timestamp, timestampReadable, originalUrl, archiveUrl, statusCode, mimeType, digest, length, isFirst, isLast, firstSeen, lastSeen; plus SNAPSHOTS_XLSX/CSV.

Behavior: read-only; runs the Apify Actor pandadad0214/wayback-snapshot-finder (https://apify.com/pandadad0214/wayback-snapshot-finder) on your own Apify account. Price: $0.001 per snapshot returned. Runs that find nothing are not charged per result, and spending is capped per call by run_max_charge_usd (default $0.50). run_max_items (default 50) limits items returned and fills maxResults when you leave it unset, so it also limits what is billed; setting maxResults higher can bill more than is returned. Most calls finish in 5-15 s for a few inputs; large inputs or crawls can take minutes, so raise run_timeout_secs (max 300) or shrink the input after a timeout error. Returns JSON {actor, count, items}; long text output is trimmed to whole items, with all items in structuredContent.

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": "wayback_snapshot_finder"
  }
}

Input Schema

NameRequiredDescriptionDefault
toNoTo date. Latest snapshot: YYYY or YYYYMMDD.
fromNoFrom date. Earliest snapshot: YYYY or YYYYMMDD (e.g. 2015 or 20150101).
urlsNoURLs. Pages or hosts to look up (https:// and www. are fine). Duplicates are dropped.
domainsNoDomains. Whole domains to search (always uses domain match). Combine with URLs if you want.
closestToNoClosest to timestamp. Optional. Return snapshots nearest this date/time (YYYYMMDD or YYYY-MM-DD). Sorted by closeness.
matchTypeNoMatch type (for URLs). exact = that URL only; domain = any URL on the host; prefix = that path and below. Choices: exact = Exact URL; domain = Whole domain; prefix = URL prefix.domain
maxResultsNoMaximum results. You pay per snapshot returned, so this also caps the cost. Default 100 (hard max 5000).
filterStatusNoHTTP status filter. Only keep this status code (e.g. 200). Leave empty for all.
run_max_itemsNoOptional. Most results to return from this call (default from PANDA_MAX_ITEMS, 50). Also limits how many results the Actor produces and charges for, unless you set its own max field.
collapseDigestNoUnique content only (collapse by digest). One row per unique page content. On by default.
includeFirstLastNoMark first and last seen. Probe CDX for the earliest and latest capture of each URL and set isFirst / isLast (and firstSeen / lastSeen).
maxResultsPerUrlNoMax snapshots per URL. Cap per URL/domain before the global max. Default 100.
run_timeout_secsNoOptional. Seconds to wait for results (default from PANDA_TIMEOUT_SECS, 120; max 300).
run_max_charge_usdNoOptional. Hard spending cap for this call in USD (default from PANDA_MAX_CHARGE_USD, 0.50).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.8/5.0
Behavior5/5

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

Goes well past the readOnlyHint/openWorldHint annotations: it discloses the underlying Actor and that it runs on the caller's own Apify account, per-snapshot pricing ($0.001), that empty runs are free, the run_max_charge_usd spending cap, default item limits, expected latency (5-15s typical, up to minutes) and timeout remediation, plus a full field list of what is returned. That is exactly the cost/auth/latency context annotations cannot carry.

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?

Purpose and sibling differentiation are front-loaded, then usage, then parameters, then behavior/cost – a sensible order with no filler sentences. It is dense and long, however; the parameter block reads as run-on prose that could be split or trimmed for faster scanning.

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?

For a 14-parameter tool with no output schema, the description still covers return fields, result envelope ({actor, count, items}), cost model, latency, timeout handling, and per-parameter interactions. Nothing material an agent would need to invoke this correctly or predict its cost is missing.

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, but the description adds genuine cross-parameter interaction semantics the schema does not state: maxResultsPerUrl is applied before maxResults, maxResults caps billed snapshots, run_max_items fills maxResults when unset, and includeFirstLast adds latency. It stops short of explaining matchType/domains precedence beyond noting domains always uses domain match.

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?

Opens with a specific verb+resource ('Find Internet Archive Wayback Machine snapshots') and specifies scope ('pages or whole domains') plus the mechanism ('official CDX API'). It explicitly distinguishes itself from website_change_monitor and reference_checker, so an agent can route without reading either 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?

Gives four concrete positive use cases (cite/recover a dead link, prove what a page said on a date, date first appearance, enumerate a domain's archive) and two explicit exclusions naming the alternative tool for each (live fetch/diff → website_change_monitor; full content download → not this tool).

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