internet-archive-mcp-server
Server Details
Search the Wayback Machine and IA library (40M+ items), fetch snapshots, item metadata, and text.
- Status
- Healthy
- Uptime
- 99.9% over 21 days
- Last Tested
- Transport
- Streamable HTTP · MCP 2025-11-25
- URL
- Repository
- cyanheads/internet-archive-mcp-server
- GitHub Stars
- 4
- Server Listing
- @cyanheads/internet-archive-mcp-server
TDQS
Scored across 5 tools
The two resource families are clearly split: Wayback snapshot tools (ia_find_snapshots to discover timestamps vs. ia_get_snapshot to fetch content) and item tools (ia_search_items → ia_get_item → ia_get_text). The descriptions explicitly cross-reference each other to steer selection, though ia_find_snapshots bundles two distinct modes (closest vs. history) and ia_get_item/ia_get_text could be momentarily confused by a hurried agent.
Every tool follows the same ia_<verb>_<noun> pattern: ia_find_snapshots, ia_get_snapshot, ia_get_item, ia_get_text, ia_search_items. Verbs (find/get/search) are conventional and used consistently for their respective semantics.
Five tools is lean but each covers a necessary step in the two workflows (search → metadata → text; find → fetch). It sits at the thin end of the ideal range, with no filler tools and no obviously missing sibling.
Core read-only workflows are covered: library search, item metadata/manifest, OCR text extraction, snapshot discovery with pagination, and snapshot replay. Gaps are minor and workaroundable — binary/audio/movie files are only reachable via raw URLs from the manifest, and there is no full-text search inside items or collection-browsing tool.
Available Tools
5 toolsia_find_snapshotsFind Wayback Machine SnapshotsARead-onlyIdempotentInspect
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.
| Name | Required | Description | Default |
|---|---|---|---|
| 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. |
TDQS
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.
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.
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.
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.
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.
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.
ia_get_itemGet Internet Archive ItemARead-onlyIdempotentInspect
Retrieve metadata and the file manifest for an Internet Archive item by identifier. Returns title, creator, description, subjects, collections, license, language, the total file count, and a page of files, each with its format, size, and direct download URL. Pages hold up to max_files files (default 50, at most 500 per call) starting at file_offset; set format to keep a single file type (e.g. "DjVuTXT", "Text PDF", "VBR MP3"). The primary tool to act on a search result from ia_search_items. Use ia_get_text to retrieve the readable text of a text item.
| Name | Required | Description | Default |
|---|---|---|---|
| format | No | Keep only files whose format equals this value, ignoring case — e.g. "DjVuTXT", "Text PDF", "VBR MP3". Applied before paging. Omit to list every format. | |
| max_files | No | Maximum number of files to return (default 50). One call returns at most 500: a larger value (up to 300,000) is served as 500, with a notice naming the next file_offset. | |
| identifier | Yes | Internet Archive item identifier, e.g. "prideprejudice00aust" (Pride and Prejudice). Obtain from ia_search_items results. | |
| file_offset | No | Zero-based position in the (format-filtered) file list to start from (default 0). To read the next page, add the number of files returned to the previous file_offset, or pass the file_offset the notice names. |
Output Schema
| Name | Required | Description |
|---|---|---|
| cap | No | The page size applied: max_files, or 500 when a larger value was capped. |
| date | No | Publication or upload date when provided. |
| error | No | Present when the call failed. Absent on success. |
| files | No | This page of the manifest in upstream order — up to max_files files (at most 500) from file_offset, after the format filter. |
| shown | No | Number of files returned on this page. |
| title | No | Item title when provided by the metadata. |
| notice | No | Paging guidance with the next file_offset, or the formats present when the filter matched nothing. |
| rights | No | Rights statement when provided. |
| creator | No | Creator or author name(s) when provided. |
| subject | No | Subject or topic tag(s) when provided. |
| language | No | Language(s) of the item when provided. |
| mediatype | No | Media type (texts, audio, movies, etc.). |
| truncated | No | True when more files remain past this page. |
| collection | No | Collection(s) this item belongs to when provided. |
| file_count | No | Total number of files in the full item manifest, before filtering and paging. |
| identifier | No | The item identifier. |
| licenseurl | No | License URL when provided. |
| totalCount | No | Number of files matching the format filter, before paging. |
| description | No | Item description when provided. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations cover read-only, idempotent, and open-world traits, but the description adds substantive behavioral detail beyond them: the default and hard cap on files per page, the notice returned when max_files exceeds the cap, that format filtering occurs before paging, and the zero-based offset model. This is rich operational context for a paged retrieval tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with purpose and then layers on return summary and usage guidance in a logical order. It is efficient and readable, though the long enumeration of returned metadata fields is somewhat redundant given the output schema and could be trimmed.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema, complete annotations, and 100% parameter coverage, the description supplies everything else an agent needs: scope, return shape summary, pagination limits, format filtering, and sibling alternatives. Nothing material is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already fully documents identifier, format, max_files, and file_offset. The description restates the paging and filtering behavior but adds no syntax or constraints not already present in the schema, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource: retrieve metadata and the file manifest for an Internet Archive item by identifier. It enumerates the returned metadata fields and makes clear it is distinct from ia_get_text, so the agent can identify it immediately.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly names the upstream context ('primary tool to act on a search result from ia_search_items') and the alternative for text retrieval (ia_get_text). It also explains when to use the format filter and pagination, leaving little to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
ia_get_snapshotGet Wayback Machine Snapshot ContentARead-onlyIdempotentInspect
Fetch the archived content of a URL at a specific Wayback Machine timestamp. Resolves to the nearest available capture when the exact timestamp has no snapshot. Returns the archived page as readable plain text (HTML stripped) and the replay URL of the capture Wayback served, for browser access. Use ia_find_snapshots first to discover valid timestamps for a URL.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | The URL whose archived content to retrieve. | |
| timestamp | Yes | Target Wayback timestamp in YYYYMMDDHHMMSS format (or any prefix). The nearest available snapshot will be resolved and fetched. Example: "20200101120000" for noon on January 1, 2020. |
Output Schema
| Name | Required | Description |
|---|---|---|
| text | No | Readable plain text extracted from the archived HTML: scripts, styles, comments, and tags removed, character references decoded, whitespace collapsed. Capped at the server-configured IA_MAX_SNAPSHOT_CHARS limit (default 50 000 characters). Taken from at most the first 4 MiB of the page; a notice says so when a page is longer. |
| error | No | Present when the call failed. Absent on success. |
| notice | No | Set when the page is longer than the 4 MiB read limit: the text comes from its first bytes only. |
| replay_url | No | Wayback Machine replay URL (https://web.archive.org) of the capture the text came from — where the fetch ended after any redirect Wayback issued to the capture it served. |
| resolved_status | No | HTTP status Wayback replayed the capture the text came from with — the same capture as resolved_timestamp and replay_url. |
| resolved_timestamp | No | Timestamp (YYYYMMDDHHMMSS) of the capture the text came from, read from replay_url. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, openWorld and idempotent, so safety is covered; the description adds genuinely new behavioral context — that a missing exact timestamp silently resolves to the nearest capture, that output is HTML-stripped plain text, and that a replay URL is returned for browser access. These are non-obvious traits an agent could not infer from the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three tight sentences, front-loaded with the core action, followed by resolution behavior, output shape, and the sibling prerequisite. Every sentence carries distinct information with no padding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, return-value documentation is not required, yet the description still characterizes output as readable plain text plus a replay URL. For a two-parameter, fully annotated read tool, nothing an agent needs to invoke it correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3: the schema already explains both url and the YYYYMMDDHHMMSS timestamp format with prefix tolerance and an example. The description's 'nearest available capture' note restates what the timestamp schema description already says, adding little beyond the structured fields.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Precise verb+resource pair ('Fetch the archived content of a URL') with the Wayback Machine timestamp scope made explicit. It is distinguishable from siblings like ia_get_text and ia_get_item, and it names ia_find_snapshots as the prerequisite discovery tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
States an explicit ordering rule: 'Use ia_find_snapshots first to discover valid timestamps for a URL,' which routes the agent to the correct sibling before invoking this one. Combined with the snapshot-resolution semantics, the agent knows both when and how to call it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
ia_get_textGet Internet Archive Item TextARead-onlyIdempotentInspect
Retrieve readable OCR DjVuTXT or plain text from an Internet Archive item, including public-domain books, documents, scanned periodicals, and transcripts. Set max_chars for page size, then pass next_continuation as continuation with the same identifier and omit char_offset. Direct char_offset access remains available. To confirm a text file exists, call ia_get_item with format "DjVuTXT".
| Name | Required | Description | Default |
|---|---|---|---|
| max_chars | No | Maximum number of characters to return in this response. Defaults to the server-configured maximum (IA_MAX_SNAPSHOT_CHARS, typically 50 000); a larger value is served at that maximum, with a notice. Lower values reduce token usage. | |
| identifier | Yes | Internet Archive item identifier, e.g. "prideprejudice00aust" (Pride and Prejudice). Obtain from ia_search_items results. | |
| char_offset | No | Character offset to start reading from (default 0). For sequential pages use next_continuation as continuation instead. Omit char_offset when using continuation. | |
| continuation | No | Opaque next_continuation from the previous page. Omit char_offset when using it; blank is omitted. |
Output Schema
| Name | Required | Description |
|---|---|---|
| text | No | The text slice starting at char_offset up to max_chars characters. |
| error | No | Present when the call failed. Absent on success. |
| notice | No | Explains a max_chars clamp or why efficient continuation is unavailable, with the next char_offset or end-of-document status. |
| has_more | No | True when there is more text beyond this slice. Use next_continuation, or add max_chars to char_offset if no token is available. |
| max_chars | No | Maximum characters this response could hold — the requested max_chars, or the server maximum when the request exceeded it. |
| char_offset | No | Character offset used for this response. |
| source_file | No | Filename of the source text file fetched from the item. |
| next_continuation | No | Opaque next-page token; use as continuation with the same identifier and omit char_offset. Expires after one hour. |
| source_file_bytes | No | Size of the source text file in bytes, from the item manifest — a byte count, not a character count (non-ASCII text takes several bytes per character). Omitted when the manifest lists no size. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and openWorldHint, so the safety profile is largely covered. The description adds useful behavioral context about page sizing, continuation handling, and the fallback check for whether a text file exists, but it does not describe failure modes when no OCR text is available.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with purpose, then moves efficiently into pagination mechanics and an alternative tool for file-existence checks. Every sentence carries operational value with no unnecessary repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given rich annotations, full schema coverage, and an output schema, the description provides everything needed to select and invoke the tool correctly. It covers what is retrieved, how to page through results, and how to verify that a text file exists before using this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the parameters are already well documented. The description reinforces max_chars as page size and continuation as coming from next_continuation, but most of this restates or lightly contextualizes what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource: retrieve readable OCR DjVuTXT or plain text from an Internet Archive item. It also scopes the content types and explicitly distinguishes the existence-check path via ia_get_item, so an agent can tell this apart from related item/snapshot tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives clear operational guidance for pagination: set max_chars, then pass next_continuation as continuation with the same identifier and omit char_offset. It also names ia_get_item as the alternative for confirming a text file exists, though it does not exhaustively contrast against all sibling tools such as ia_get_snapshot or ia_search_items.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
ia_search_itemsSearch Internet Archive ItemsARead-onlyInspect
Search the Internet Archive library (40M+ items) using the Advanced Search (Solr) API. Filter by media type (texts, audio, movies, software, image, etc.), collection, creator, date range, and language. Sort by downloads (the default), date, title, or random. Supports pagination via page/rows. Returns identifiers, titles, creators (the first 10, with creator_count when a record lists more), media types, dates, download counts, collections (without fav- favorites lists), total_found, and current page/rows for pagination context. Use ia_get_item with a returned identifier to get full metadata and file manifests.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Page number (1-indexed). Combine with rows for pagination. Advanced Search serves only the first 10,000 results, so page × rows ≤ 10,000 (page 50 at 200 rows, page 200 at 50). | |
| rows | No | Number of results per page (default 50). One call returns at most 200: on page 1 a larger value (up to 10,000) is served as 200 with a notice naming the next page; on later pages a value above 200 is rejected. | |
| sort | No | Sort order in Solr format: a sortable field followed by asc or desc, e.g. "downloads desc", "date asc", "publicdate desc", "titleSorter asc", or "random". Default: "downloads desc". Advanced Search has no relevance sort. Except under random, results tied under the sort are ordered by identifier, so consecutive pages neither repeat nor skip an item. | |
| query | Yes | Solr query string. Supports field prefixes such as title:"war and peace", creator:dickens, subject:history. Plain keywords search all fields. Put a URL in quotes. At most 2,047 characters, a limit the filters below also count toward. | |
| creator | No | Filter by creator name, e.g. "Charles Dickens". | |
| date_to | No | Inclusive end of date range: YYYY, YYYY-MM, or YYYY-MM-DD. A year or month ends on its last day; blank means no upper bound. Must be a real Gregorian date. | |
| language | No | Filter by language code or name, e.g. "eng" or "English". | |
| date_from | No | Inclusive start of date range: YYYY, YYYY-MM, or YYYY-MM-DD. A year or month starts on its first day; blank means no lower bound. Must be a real Gregorian date. | |
| mediatype | No | Filter by media type: texts, movies, audio, software, image, data, web, collection, etree (live concert recordings), or account. Case-insensitive; text, book, and books mean texts, movie, video, and videos mean movies, images means image, and collections means collection. Any other value is rejected. | |
| collection | No | Filter to items within a specific collection identifier, e.g. "gutenberg" or "librivoxaudio". |
Output Schema
| Name | Required | Description |
|---|---|---|
| cap | No | The per-call cap applied to rows (200). |
| page | No | Current page number (1-indexed). |
| rows | No | Rows per page applied: the requested rows, or 200 when a larger value was capped. |
| error | No | Present when the call failed. Absent on success. |
| items | No | Items matching the search query. |
| shown | No | Number of items returned. |
| notice | No | Guidance when the page came back empty — nothing matched (naming the mediatype filter applied, if any), or the requested page is past the last page of results — or when rows was capped, naming the rows and page that continue. |
| truncated | No | True when rows above 200 was served at 200 and more results remain. |
| total_found | No | Total number of matching items across all pages. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and openWorldHint, and the description goes further by disclosing real quirks: creators are truncated to the first 10 with creator_count, favorites lists are excluded from collections, and total_found/page/rows are returned for pagination context. The 10,000-result ceiling is left to the schema rather than surfaced here, a minor gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with purpose and scale, then filters, sorting, pagination, and return shape in a logical order. Dense but nearly every clause carries information; the return-value inventory is the one part that partly duplicates the output schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 10 parameters, a full schema, annotations, and an output schema, the description covers everything an agent needs to call correctly: filtering dimensions, sort semantics, pagination model, what comes back, and the natural next tool. Nothing essential is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and the parameter docs are already detailed (Solr syntax, date formats, mediatype aliases), so the schema carries the weight. The description adds only a high-level restatement of the filter and sort options, which is baseline-appropriate but not additive.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Search the Internet Archive library') plus the underlying API and scale (40M+ items). It also names the sibling it hands off to ('Use ia_get_item with a returned identifier'), so an agent can distinguish search from item retrieval without opening either schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Clearly frames the tool as a discovery step whose results feed ia_get_item for full metadata, and names the filter dimensions available. It doesn't state when to prefer it over ia_find_snapshots or ia_get_text, so sibling routing is only partially covered.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
3 tool updates
- Changed
ia_find_snapshots4 fields changed- changed
Input schema / properties / resume_key / descriptionPrevious 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." - changed
Output schema / properties / error / properties / data / properties / reason / descriptionPrevious 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." - changed
Output schema / properties / error / properties / data / properties / reason / examplesPrevious 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" +] - changed
Output schema / properties / notice / descriptionPrevious 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."
- Changed
ia_get_text8 fields changed- removed
Input schema / properties / char_offset / defaultRemoved value: -0 - changed
Input schema / properties / char_offset / descriptionPrevious value: -"Character offset to start reading from (default 0). To read the next page, add max_chars to the previous char_offset."New value: +"Character offset to start reading from (default 0). For sequential pages use next_continuation as continuation instead. Omit char_offset when using continuation." - added
Input schema / properties / continuationAdded value: +{ + "description": "Opaque next_continuation from the previous page. Omit char_offset when using it; blank is omitted.", + "type": "string" +} - changed
Output schema / properties / error / properties / data / properties / reason / descriptionPrevious value: -"Machine-readable failure mode. Declared by this tool: `item_not_found`: The identifier does not exist in the Internet Archive. `no_text_file`: The item exists but contains no readable text file (DjVuTXT or plain-text). `download_forbidden`: Access to this item is restricted — it is in a login-required or limited collection. `archive_unavailable`: The Internet Archive Metadata API or the text file download did not answer within the request timeout, could not be reached, answered HTTP 5xx after retries, 429, or another 4xx, or the metadata response was unreadable. Other values are possible when a failure originates below the handler."New value: +"Machine-readable failure mode. Declared by this tool: `invalid_continuation`: A continuation is unknown, expired, belongs to another item, or its file changed. `range_unavailable`: The download ignored or returned an invalid conditional byte range. `ambiguous_pagination`: Both a nonblank continuation and char_offset were supplied. `item_not_found`: The identifier does not exist in the Internet Archive. `no_text_file`: The item exists but contains no readable text file (DjVuTXT or plain-text). `download_forbidden`: Access to this item is restricted — it is in a login-required or limited collection. `archive_unavailable`: The Internet Archive Metadata API or the text file download did not answer within the request timeout, could not be reached, answered HTTP 5xx after retries, 429, or another 4xx, or the metadata response was unreadable. Other values are possible when a failure originates below the handler." - changed
Output schema / properties / error / properties / data / properties / reason / examplesPrevious value: -[ - "item_not_found", - "no_text_file", - "download_forbidden", - "archive_unavailable" -]New value: +[ + "invalid_continuation", + "range_unavailable", + "ambiguous_pagination", + "item_not_found", + "no_text_file", + "download_forbidden", + "archive_unavailable" +] - changed
Output schema / properties / has_more / descriptionPrevious value: -"True when there is more text beyond this slice. Increment char_offset by max_chars to read the next page."New value: +"True when there is more text beyond this slice. Use next_continuation, or add max_chars to char_offset if no token is available." - added
Output schema / properties / next_continuationAdded value: +{ + "description": "Opaque next-page token; use as continuation with the same identifier and omit char_offset. Expires after one hour.", + "type": "string" +} - changed
Output schema / properties / notice / descriptionPrevious value: -"Set when max_chars exceeded the server maximum (IA_MAX_SNAPSHOT_CHARS) and was served at it, naming the char_offset of the next page, or saying the page reaches the end of the document."New value: +"Explains a max_chars clamp or why efficient continuation is unavailable, with the next char_offset or end-of-document status."
- Changed
ia_search_items4 fields changed- changed
Input schema / properties / date_from / descriptionPrevious value: -"Start of date range filter in YYYY-MM-DD format. Example: \"1900-01-01\"."New value: +"Inclusive start of date range: YYYY, YYYY-MM, or YYYY-MM-DD. A year or month starts on its first day; blank means no lower bound. Must be a real Gregorian date." - changed
Input schema / properties / date_to / descriptionPrevious value: -"End of date range filter in YYYY-MM-DD format. Example: \"1999-12-31\"."New value: +"Inclusive end of date range: YYYY, YYYY-MM, or YYYY-MM-DD. A year or month ends on its last day; blank means no upper bound. Must be a real Gregorian date." - changed
Output schema / properties / error / properties / data / properties / reason / descriptionPrevious value: -"Machine-readable failure mode. Declared by this tool: `invalid_mediatype`: mediatype is not an Internet Archive media type or one of its recognized spellings. `page_limit_exceeded`: page × rows exceeds 10,000, the last result Advanced Search serves. `rows_over_cap`: rows is above 200 on a page after the first. `invalid_query`: Advanced Search rejected the query syntax, an unquoted URL, the query length, or the sort field. `search_unavailable`: Advanced Search failed, rate-limited the request, returned an unreadable response, timed out, or could not be reached (network error). Other values are possible when a failure originates below the handler."New value: +"Machine-readable failure mode. Declared by this tool: `invalid_date_range`: date_from or date_to is not a real Gregorian year, month, or date. `invalid_mediatype`: mediatype is not an Internet Archive media type or one of its recognized spellings. `page_limit_exceeded`: page × rows exceeds 10,000, the last result Advanced Search serves. `rows_over_cap`: rows is above 200 on a page after the first. `invalid_query`: Advanced Search rejected the query syntax, an unquoted URL, the query length, or the sort field. `search_unavailable`: Advanced Search failed, rate-limited the request, returned an unreadable response, timed out, or could not be reached (network error). Other values are possible when a failure originates below the handler." - changed
Output schema / properties / error / properties / data / properties / reason / examplesPrevious value: -[ - "invalid_mediatype", - "page_limit_exceeded", - "rows_over_cap", - "invalid_query", - "search_unavailable" -]New value: +[ + "invalid_date_range", + "invalid_mediatype", + "page_limit_exceeded", + "rows_over_cap", + "invalid_query", + "search_unavailable" +]
5 tool updates
- First observed
ia_find_snapshots - First observed
ia_get_item - First observed
ia_get_snapshot - First observed
ia_get_text - First observed
ia_search_items
Related MCP Connectors
Archive MCP — wraps the Internet Archive APIs (free, no auth)
Search books and authors across Open Library, the Internet Archive open catalog.
LLM-ready web search + instant answers + URL-to-clean-text fetch for agents and RAG.
Wayback Machine for agents: closest archived copy of a URL with its text, and full capture history
Related MCP Servers
- AlicenseNot gradedqualityDmaintenanceProvides tools to query the Internet Archive, including enumerating historical captures, listing revisions, reading snapshots as clean text, diffing captures, and searching archived items.19 npmMIT
- AlicenseNot gradedqualityBmaintenanceEnables searching the Internet Archive for texts, audio, video, and software; retrieving detailed metadata for archived items; checking Wayback Machine snapshots for URLs; and listing downloadable files.446 npmMIT
- AlicenseNot gradedqualityBmaintenanceProvides read-only access to the Internet Archive's Wayback Machine and catalog, enabling retrieval of archived web captures, snapshot metadata, and catalog search.BSD 3-Clause
- AlicenseAqualityCmaintenanceMCP server for the Internet Archive's Wayback Machine. Search archived snapshots, extract page text from a specific date, track how a site has changed over time, check if broken links are recoverable, and perform research across Internet Archive collections.640 PyPI3MIT
Glama MCP Gateway
Add one secure layer between your agents and this server.