internet-archive-mcp-server

Find Wayback Machine Snapshots

ia_find_snapshots

Read-onlyIdempotent

Find Wayback Machine snapshots of a URL. Mode "closest" returns the single nearest capture to a given timestamp via the Availability API, falling back to a CDX closest-capture query when the Availability API has no answer (one result). Mode "history" returns the full capture list via the CDX API — filterable by date range and HTTP status code, collapsed by default to one capture per day (collapse "timestamp:8"); collapse "timestamp:14" lists one row per distinct capture second. Use history mode to survey how a page changed over time; use closest mode when you need the snapshot nearest a specific date. History mode returns up to limit records (at most 10,000 per call) and supports resume-key pagination for URLs with very large capture histories.

Input Schema

Name	Required	Description
`to`	No	End of date range filter in YYYYMMDD format (history mode only). Example: "20231231".
`url`	Yes	The URL to look up in the Wayback Machine.
`from`	No	Start of date range filter in YYYYMMDD format (history mode only). Example: "20200101".
`mode`	Yes	Lookup mode: "closest" returns the single nearest snapshot to the given timestamp; "history" returns the paginated full capture list via the CDX API.
`limit`	No	Maximum number of CDX records to return (history mode only, default 100). One call returns at most 10,000: a larger value (up to 150,000) is served as 10,000, and the resume_key continues from there.
`collapse`	No	CDX collapse parameter (history mode only). Format: "timestamp:N" where N is 1–14 (4=year, 6=month, 8=day, 10=hour, 14=second): consecutive captures sharing the first N timestamp digits are listed once. Omitted or blank, it is "timestamp:8", one capture per day. Pass "timestamp:14" for one row per distinct capture second.
`timestamp`	No	Target timestamp in YYYYMMDDHHMMSS format (or any prefix thereof). Required for mode=closest. Example: "20200101" for January 1, 2020.
`resume_key`	No	Opaque pagination key from a previous history mode response. Pass this to continue from where the last page left off. Server cursors expire after one hour and bind the URL and original filters; omit filters on continuation or repeat their original values. Page size may change. Wildcard and legacy raw continuations can omit collapsed captures.
`status_filter`	No	Filter CDX results to a specific HTTP status code (history mode only). Must be a 3-digit numeric code. Example: "200" to return only successful captures.

Output Schema

Name	Required	Description
`cap`	No	The limit applied: limit, or 10,000 when a larger value was capped.
`error`	No	Present when the call failed. Absent on success.
`shown`	No	Number of snapshots returned.
`notice`	No	Pagination guidance, cap disclosure, or limitations of legacy raw continuation.
`snapshots`	No	List of snapshots matching the query.
`truncated`	No	True when the snapshot list was capped at the limit.
`resume_key`	No	Opaque key to pass as resume_key in the next call to continue paginating CDX history results.

Schema Changelog

Changes observed during successful MCP inspections.

Changed4 schema fields changedOct 24, 2026

changedInput schema / properties / resume_key / description

Previous value: -"Opaque pagination key from a previous history mode response. Pass this to continue from where the last page left off."New value: +"Opaque pagination key from a previous history mode response. Pass this to continue from where the last page left off. Server cursors expire after one hour and bind the URL and original filters; omit filters on continuation or repeat their original values. Page size may change. Wildcard and legacy raw continuations can omit collapsed captures."

changedOutput schema / properties / error / properties / data / properties / reason / description

Previous value: -"Machine-readable failure mode. Declared by this tool: `missing_timestamp`: Closest mode was called without a timestamp, or with a blank one. `no_snapshots`: No snapshots found for the given URL with the current filters. `no_snapshot_available`: Closest mode: no capture exists near the requested timestamp for this URL. Either mode: the Wayback Machine does not serve captures of this URL at all — the CDX or Availability API answered HTTP 403, 410, or 451, as it does for a site excluded from the archive. `cdx_unavailable`: The Wayback CDX API answered HTTP 5xx after retries or 429, refused the request with another 4xx, did not answer within the request timeout, could not be reached, or returned an unreadable response; in closest mode, the CDX closest-capture check failed or did not complete in time. `availability_unavailable`: The Wayback Availability API answered HTTP 5xx after retries or 429, refused the request with another 4xx, did not answer within the request timeout, could not be reached, or returned an unreadable response (closest mode). Other values are possible when a failure originates below the handler."New value: +"Machine-readable failure mode. Declared by this tool: `invalid_resume_key`: The server history cursor is malformed, expired, or unavailable for this caller. `resume_key_conflict`: An explicit URL or filter conflicts with the server history cursor. `missing_timestamp`: Closest mode was called without a timestamp, or with a blank one. `no_snapshots`: No snapshots found for the given URL with the current filters. `no_snapshot_available`: Closest mode: no capture exists near the requested timestamp for this URL. Either mode: the Wayback Machine does not serve captures of this URL at all — the CDX or Availability API answered HTTP 403, 410, or 451, as it does for a site excluded from the archive. `cdx_unavailable`: The Wayback CDX API answered HTTP 5xx after retries or 429, refused the request with another 4xx, did not answer within the request timeout, could not be reached, or returned an unreadable response; in closest mode, the CDX closest-capture check failed or did not complete in time. `availability_unavailable`: The Wayback Availability API answered HTTP 5xx after retries or 429, refused the request with another 4xx, did not answer within the request timeout, could not be reached, or returned an unreadable response (closest mode). Other values are possible when a failure originates below the handler."

changedOutput schema / properties / error / properties / data / properties / reason / examples

Previous value: -[
-  "missing_timestamp",
-  "no_snapshots",
-  "no_snapshot_available",
-  "cdx_unavailable",
-  "availability_unavailable"
-]New value: +[
+  "invalid_resume_key",
+  "resume_key_conflict",
+  "missing_timestamp",
+  "no_snapshots",
+  "no_snapshot_available",
+  "cdx_unavailable",
+  "availability_unavailable"
+]

changedOutput schema / properties / notice / description

Previous value: -"Set when the list was capped: how to continue, naming resume_key."New value: +"Pagination guidance, cap disclosure, or limitations of legacy raw continuation."

First observedOct 12, 2026

TDQS

A4.1/5.0

Behavior4/5

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

Adds real behavioral detail beyond the readOnly/idempotent/openWorld annotations: the Availability API fallback to a CDX closest-capture query, the 10,000-record-per-call ceiling despite a 150,000 max, and resume-key pagination. The schema carries the cursor-expiry caveats, so the description doesn't repeat them, but it also doesn't mention error/empty-result behavior.

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 long but dense sentences, front-loaded with the core action and mode contract. Slightly heavy for a two-sentence description, but every clause (fallback, collapse defaults, pagination ceiling) carries operational information.

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 need not document return shapes, and the 9 parameters are fully covered in the schema. The description fills the remaining gap — how the two modes actually behave and how pagination works — so an agent can call this correctly without guessing.

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 earns a 4 by adding cross-parameter meaning the schema doesn't — which mode each filter applies to, and that a limit above 10,000 is silently served as 10,000 with the resume_key continuing the remainder.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb+resource (find Wayback Machine snapshots of a URL) and clearly splits the resource into two named modes with distinct outputs. It does not distinguish itself from sibling ia_get_snapshot, which an agent could plausibly confuse with the 'closest' mode.

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 explicit mode-selection guidance: 'Use history mode to survey how a page changed over time; use closest mode when you need the snapshot nearest a specific date.' No when-not-to-use guidance and no comparison to sibling tools such as ia_get_snapshot or ia_get_text.

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

All internet-archive-mcp-server 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.