Provides tools to interact with the Internet Archive's Wayback Machine, including archiving URLs, retrieving archived pages as clean text, listing snapshots, searching items, and comparing snapshots.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@mcp-archive Get readable text of https://example.com archived in 2020"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
6 Wayback Machine + Internet Archive tools for Claude. The one that doesn't blow your context window. Free, MIT.
Existing Wayback MCPs either dump raw HTML (blowing up the LLM context window) or are abandoned forks. mcp-archive returns clean readable text — stripped HTML, scripts, nav, Wayback toolbar — so you can actually fit archived pages in a Claude conversation.
{
"mcpServers": {
"archive": {
"command": "npx",
"args": ["-y", "@dpm-tools/mcp-archive"]
}
}
}Requires Node.js 22.18+.
Related MCP server: MCP Wayback Machine Server
archive_url — Push a URL to Wayback right now. Returns snapshot URL.
get_archived — Get nearest Wayback snapshot for a URL/date.
list_snapshots — List Wayback snapshots in a date range (CDX API).
fetch_archived_text ⭐ — Fetches archived page and returns CLEAN READABLE TEXT (strips HTML, scripts, nav, toolbar). The key differentiator.
search_archive_items — Search Internet Archive items (books, audio, video, software).
compare_snapshots — Compare two snapshots of the same URL by extracted text.
"Archive this URL right now: https://example.com/important-page"
"What did news.ycombinator.com look like on 2020-01-01?"
"List all archived versions of openai.com from 2023."
"Fetch the readable text of https://example.com archived in 2024."
"Search the Internet Archive for 'public domain javascript books'."
"Compare https://example.com between 2020 and 2024 — what changed?"
See examples/prompts.md for more.
Researchers, journalists, and link-rot fighters need Wayback access. Existing MCPs in this space:
5+ personal forks, mostly abandoned
Most return raw HTML — instantly blows up Claude's context window
None offer text extraction + truncation
mcp-archive solves it: regex-only HTML→text extraction (no jsdom/cheerio deps), Wayback toolbar stripping, configurable max_chars. The id_ flag is used on snapshot URLs to fetch raw content without the toolbar at the source.
Zero API keys. Custom User-Agent. 200ms inter-call sleep on rate-limited operations to respect archive.org TOS.
Wayback Machine availability API (archive.org/wayback/available)
Wayback CDX search (web.archive.org/cdx/search/cdx)
Wayback save API (web.archive.org/save/)
Internet Archive advanced search (archive.org/advancedsearch.php)
@dpm-tools/mcp-devkit — 15 dev utilities (UUID, hash, JWT, JSON, cron, color)
@dpm-tools/mcp-public-data — sun, moon, holidays, geocoding (keyless)
@dpm-tools/mcp-diff — diff, patch, 3-way merge
MIT © dpm (digital product mill)
Submit a URL to be archived right now by the Wayback Machine. Returns the snapshot URL once captured.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | URL to archive (http/https) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; the description only mentions return of the snapshot URL. It does not disclose side effects, rate limits, authentication needs, or whether the archiving is synchronous. The statement 'right now' hints at immediacy but lacks specificity.
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 a single sentence that efficiently conveys the tool's purpose and result, with no superfluous content.
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 tool's simplicity (one parameter, no output schema), the description is minimally adequate but lacks information on preconditions (e.g., URL accessibility), idempotency, or error handling.
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 baseline is 3. The description adds no extra meaning beyond the schema's parameter description, and no additional validation or format hints are given.
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 clearly states the action ('Submit a URL to be archived right now') and the resource ('Wayback Machine'), with a distinct purpose from siblings that focus on retrieval or comparison.
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?
The description implies immediate archiving but does not explicitly state when to use this tool over alternatives or provide exclusion criteria. Usage is inferred from the sibling tools' different purposes.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Compare two Wayback snapshots of the same URL by extracted text. Returns added/removed line counts and sample changes.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | ||
| date_a | Yes | ISO date or Wayback timestamp | |
| date_b | Yes | ||
| max_chars | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the full burden. It discloses the return type (line counts and sample changes) but does not mention destructive behavior, authentication needs, rate limits, or size limits implied by the max_chars parameter.
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 a single concise sentence that conveys the core purpose and output. It could be slightly improved by adding structure (e.g., listing parameters), but it is not verbose.
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?
No output schema is provided, so the description must explain the return value. It does so minimally ('line counts and sample changes'), but lacks detail on the structure of sample changes, error handling, or behavior with invalid inputs. Adequate but incomplete.
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 only 25% (only date_a has a description). The description adds minimal context ('of the same URL') but does not detail the format of date_a and date_b, nor explain the purpose of max_chars. The description fails to compensate for the low schema coverage.
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 clearly states the tool compares two Wayback snapshots by extracted text, specifying the output (added/removed line counts and sample changes). It distinguishes itself from sibling tools like list_snapshots and fetch_archived_text.
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?
The description implies usage for comparing two snapshots of the same URL but does not explicitly state when to use this tool versus alternatives (e.g., fetch_archived_text for single snapshot). No exclusions or alternatives are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch an archived snapshot and return CLEAN READABLE TEXT (strips HTML/scripts/nav/Wayback toolbar). Designed to not blow up the LLM context window.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | ||
| date | No | Optional ISO date or Wayback timestamp | |
| max_chars | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses stripping HTML/scripts/nav/Wayback toolbar and context window handling, but does not specify return format or potential rate limits. With no annotations, more detail on behavior (e.g., truncation) would be helpful.
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 sentences, front-loaded with key information (purpose, cleaning, context window). No redundant words; every sentence earns its place.
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?
Covers main aspects: what it does, cleaning, context window. Lacks explicit mention of return format or metadata, but given no output schema and simplicity of the tool, it is mostly complete.
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 low (33%), but the description adds context: cleaning and context window explain the purpose of url and max_chars. However, it does not provide explicit details for each parameter, only overarching behavior.
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?
Describes fetching an archived snapshot and returning clean readable text, which clearly states the action and output. Distinguishes itself from siblings like archive_url (archiving) and compare_snapshots (comparison) by focusing on text extraction.
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?
Implies use for obtaining clean text for LLM context, but no explicit when-not-to-use or alternatives. Sibling tools exist (e.g., get_archived might return raw HTML) but no guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the closest Wayback snapshot for a URL near a given date (defaults to most recent).
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | ||
| date | No | Optional ISO date (YYYY-MM-DD) or Wayback timestamp (YYYYMMDDHHMMSS) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must carry full burden. It states behavior (closest snapshot, default to most recent) but does not disclose error handling, authorization needs, or side effects. Adequate for a read operation but lacks completeness.
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?
Single sentence, 14 words, directly states purpose with no filler. Front-loaded and efficient.
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?
Tool is simple but lacks output schema. Description does not hint at return format (e.g., snapshot metadata, URL, status). Without annotations, more context about behavior and results would improve completeness.
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 50% (date parameter described). Description adds that date defaults to most recent, which is helpful. But url parameter lacks description and tool does not clarify expected format beyond schema.
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?
Specific verb 'Get' and resource 'Wayback snapshot' clearly state the tool's purpose. The description distinguishes from siblings like 'list_snapshots' and 'fetch_archived_text' by specifying it retrieves the closest snapshot.
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?
No explicit guidance on when to use this tool versus alternatives. While sibling names imply other use cases, the description does not provide any when-to-use or when-not-to-use advice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List Wayback snapshots for a URL, optionally filtered by date range.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | ||
| from | No | ISO date (YYYY-MM-DD) | |
| to | No | ISO date (YYYY-MM-DD) | |
| limit | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden but fails to disclose behavioral traits such as pagination, rate limits, or whether it returns metadata only. It merely states the basic function.
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?
Single sentence, 10 words, no redundancy. Front-loaded with key action and resource. Highly concise.
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 four parameters, required url, no output schema, and multiple sibling tools, the description lacks completeness. It does not explain return format, pagination (implied by limit), or differentiation from get_archived and search_archive_items.
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 50% (from and to have descriptions). The description adds 'optionally filtered by date range' but does not clarify url or limit beyond schema. Baseline 3 is appropriate as description adds minimal extra value.
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 clearly states the tool lists Wayback snapshots for a URL, with optional date range filtering. It uses specific verbs and resource, and distinguishes from siblings like compare_snapshots or fetch_archived_text.
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?
The description implies usage for listing snapshots with filters but does not provide explicit guidance on when to use this tool versus alternatives like search_archive_items. No exclusions or when-not-to-use advice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search Internet Archive items (books, audio, video, software, etc.).
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | ||
| mediatype | No | texts | |
| limit | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description only states it searches items. It does not disclose behavior such as pagination, result ordering, or what happens with empty queries.
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 a single concise sentence that is easy to read. However, it is overly terse and could be expanded to include more detail without becoming verbose.
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 no output schema and minimal parameter descriptions, the description does not provide enough context for an agent to understand what the tool returns or how it behaves. Lacks details on pagination, result format, or error handling.
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 0%. The description hints at media types ('books, audio, video, software') but does not explicitly link to the 'mediatype' parameter or explain 'query' and 'limit'. Some value added, but insufficient.
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 clearly states the tool searches Internet Archive items and lists example media types. However, it does not differentiate from sibling tools like 'get_archived' which might also search items.
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?
No guidance on when to use this tool versus alternatives like 'archive_url' or 'list_snapshots'. No context about prerequisites or limitations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.1.0archive_urlcompare_snapshotsfetch_archived_textget_archivedlist_snapshotssearch_archive_itemsEach tool has a clearly distinct purpose: submitting URLs, retrieving single snapshots, listing multiple snapshots, comparing snapshots, fetching text from a snapshot, and searching non-Wayback items. No overlap.
All tool names follow a consistent verb_noun pattern (e.g., archive_url, list_snapshots, fetch_archived_text), making the API predictable.
6 tools cover the core operations of web archiving and searching the Internet Archive catalog, neither too few nor too many.
The toolset provides a complete lifecycle for Wayback snapshots (submit, retrieve, list, compare, get text) and adds search for other archive types, with no obvious gaps.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Read a URL as clean markdown, screenshot a website, url to PDF. Web access for agents, no signup.
Web search, URL content extraction to Markdown, site mapping, and recursive web crawler.
Web tools for agents: fetch URL as markdown (free MCP) + x402 scrape, links, AI JSON, snapshot.
Wayback Machine for agents: closest archived copy of a URL with its text, and full capture history
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/jeffereychown-Max/mcp-archive'
If you have feedback or need assistance with the MCP directory API, please join our Discord server