How do I use arquivo-pt-mcp?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@arquivo-pt-mcp search for 'eleições 2005' on Arquivo.pt" 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.

arquivo-pt-mcp

by thaenor

Overview Schema Related Servers Score Discussions

Python

Remote

title: Arquivo Pt MCP emoji: 📚 colorFrom: blue colorTo: red sdk: docker app_port: 7860 pinned: false license: mit

arquivo-pt-mcp

Python Versions License: MIT

Um servidor Model Context Protocol (MCP) para o Arquivo.pt — o arquivo web português. Permite que o Claude (ou qualquer outro LLM compatível com MCP) pesquise e leia conteúdo web português arquivado.

Related MCP server: Gemini Google Web Search MCP

🇵🇹 Em Português

O que faz

O arquivo-pt-mcp expõe seis ferramentas ao modelo de linguagem, permitindo-lhe consultar o Arquivo.pt como se fosse uma base de dados nativa:

Ferramenta	Descrição
`search`	Pesquisa em texto integral no arquivo, com filtros opcionais de intervalo de datas e site
`image_search`	Pesquisa em mais de 1,8 mil milhões de imagens arquivadas
`list_versions`	Lista todas as capturas de um determinado URL através do servidor CDX
`get_snapshot`	Obtém uma página arquivada específica a partir de um URL + timestamp
`extract_text`	Obtém uma página arquivada e devolve o texto legível (HTML removido)
`get_screenshot`	Obtém o URL de uma captura PNG renderizada de uma página arquivada (opcionalmente com os bytes inline)

Instalação

pip install arquivo-pt-mcp

Ou, se preferir usar o uv:

uv add arquivo-pt-mcp

Para desenvolvimento (instalação a partir do código fonte):

git clone https://github.com/thaenor/arquivo-pt-mcp.git
cd arquivo-pt-mcp
pip install -e ".[dev]"

Configuração

🚀 Caminho mais fácil — sem instalação
Existe uma instância pública alojada em Hugging Face Spaces. Aponte qualquer cliente MCP para:
https://decaf-squirrel-arquivo-pt-mcp.hf.space/mcp
Sem Python, sem pip install, sem terminal. Basta o URL. (Ver instalação local abaixo se preferir correr no seu próprio computador.)

Claude.ai (web ou desktop) — Pro/Max/Team

A configuração mais simples para utilizadores não-técnicos.

Vá a Settings → Connectors → Add custom connector.
Name: arquivo-pt
URL: https://decaf-squirrel-arquivo-pt-mcp.hf.space/mcp
Guarde. As seis ferramentas ficam disponíveis em qualquer nova conversa.

Claude Desktop

Edite o ficheiro claude_desktop_config.json:

macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Windows: %APPDATA%\Claude\claude_desktop_config.json
Linux: ~/.config/Claude/claude_desktop_config.json

{
  "mcpServers": {
    "arquivo-pt": {
      "url": "https://decaf-squirrel-arquivo-pt-mcp.hf.space/mcp"
    }
  }
}

Reinicie o Claude Desktop.

Claude Code (CLI)

Um único comando:

claude mcp add --transport http arquivo-pt https://decaf-squirrel-arquivo-pt-mcp.hf.space/mcp

Cursor

Settings → MCP → Add server:

Name: arquivo-pt
URL: https://decaf-squirrel-arquivo-pt-mcp.hf.space/mcp

ChatGPT — Plus/Team/Enterprise

Settings → Connectors → Add → MCP server URL:

https://decaf-squirrel-arquivo-pt-mcp.hf.space/mcp

Outros clientes MCP (Zed, Cline, Windsurf, Continue, …)

Qualquer cliente que suporte o transporte Streamable HTTP do MCP pode usar o mesmo URL acima. Consulte a documentação do seu cliente para saber onde o colar.

Instalação local

A instância pública é adequada para uso casual, mas é uma máquina partilhada gratuita sem garantia de disponibilidade. Corra o servidor localmente se precisar de privacidade, cache própria, ou disponibilidade garantida.

Como servidor stdio local (Claude Desktop, Cursor, etc.):

{
  "mcpServers": {
    "arquivo-pt": {
      "command": "uvx",
      "args": ["arquivo-pt-mcp"]
    }
  }
}

O uvx (do uv) instala o pacote automaticamente na primeira execução — só precisa de ter o uv instalado.

Como servidor HTTP de longa duração:

pip install arquivo-pt-mcp        # ou: uv add arquivo-pt-mcp
arquivo-pt-mcp --transport http --host 127.0.0.1 --port 8000

Depois aponte o seu cliente para http://127.0.0.1:8000/mcp. Para expor publicamente, coloque-o atrás de um proxy inverso com TLS (Caddy, nginx, Traefik) e passe --allowed-host <hostname>.

Nota: em modo HTTP as caches em memória são partilhadas entre todos os clientes ligados.

Exemplos de utilização

Uma vez configurado, pode pedir ao Claude coisas como:

“Pesquisa no Arquivo.pt por ‘eleições 2005’ e mostra-me os primeiros três resultados.”
“Mostra-me como a página inicial do Público era a 1 de janeiro de 2010.”
“Quantas vezes foi o Expresso arquivado em 2008?”
“Extrai o texto do snapshot mais antigo do sapo.pt.”
”Procura imagens do Terreiro do Paço arquivadas antes de 2010.”
”Mostra-me uma screenshot da homepage do Público em 1 de janeiro de 2010.”

Endpoints da API utilizados

https://arquivo.pt/textsearch — pesquisa em texto
https://arquivo.pt/imagesearch — pesquisa de imagens
https://arquivo.pt/wayback/cdx — índice de capturas (CDX)
https://arquivo.pt/wayback/{timestamp}/{url} — obtenção de snapshots
https://arquivo.pt/wayback/noFrame/{timestamp}/{url} — snapshot limpo para extração de texto
https://arquivo.pt/screenshot?url=... — captura PNG renderizada
https://arquivo.pt/noFrame/replay/{timestamp}/{url} — replay sem frame para screenshot

Documentação oficial: https://github.com/arquivo/pwa-technologies/wiki/Arquivo.pt-API

Desenvolvimento

git clone https://github.com/thaenor/arquivo-pt-mcp.git
cd arquivo-pt-mcp
uv sync --extra dev
pytest -q

O projeto usa:

pytest + pytest-asyncio para testes
pytest-cov para cobertura
ruff para lint e formatação

ruff check src tests
ruff format src tests
pytest --cov=arquivo_pt_mcp

Testes de integração

Opcionalmente, pode executar os testes de integração contra a API real do Arquivo.pt:

RUN_INTEGRATION=1 pytest -m integration -v

Estes testes estão marcados com @pytest.mark.integration e são ignorados por padrão. Apenas executam quando a variável de ambiente RUN_INTEGRATION=1 está definida. No GitHub Actions podem ser disparados manualmente via workflow_dispatch.

Nota sobre o GitHub Actions: Os runners padrão do GitHub estão alojados nos EUA. A conectividade TCP transatlântica para arquivo.pt (alojado em Portugal) é por vezes pouco fiável — os testes podem falhar com httpx.ConnectError ou httpx.ConnectTimeout independentemente da qualidade do código. Por isso, os testes de integração foram removidos do agendamento noturno no CI. Podem ser disparados manualmente via workflow_dispatch quando necessário. Para execuções locais (a partir de qualquer localização na Europa) os testes passam de forma consistente.

Prémio Arquivo.pt

Este projeto foi desenvolvido para participar no Prémio Arquivo.pt, que incentiva a criação de ferramentas e aplicações que aproveitam o arquivo web português para fins educativos, científicos, culturais e técnicos.

Roadmap

Guardar Página Agora (Save Page Now) — requer credenciais de API
Cache com TTL para reduzir chamadas ao Arquivo.pt
Gestão de rate limits com retentativas exponenciais
Validação de inputs com modelos Pydantic
Suporte para pesquisa avançada por domínio e coleção
Integração com outros clientes MCP (Zed, Cline, Windsurf)

Licença

MIT

🇬🇧 In English

What it does

arquivo-pt-mcp exposes six tools to the language model, letting it query Arquivo.pt as if it were a native data source:

Tool	Description
`search`	Full-text search across the archive, with optional date range and site filters
`image_search`	Search across 1.8B+ archived images
`list_versions`	Every capture of a given URL, via the CDX server
`get_snapshot`	Resolve a URL + timestamp to a specific archived page
`extract_text`	Fetch an archived page and return its readable text (HTML stripped)
`get_screenshot`	Get the PNG render URL of an archived page (optionally embed the bytes inline)

Installation

pip install arquivo-pt-mcp

Or with uv:

uv add arquivo-pt-mcp

For development (install from source):

git clone https://github.com/thaenor/arquivo-pt-mcp.git
cd arquivo-pt-mcp
pip install -e ".[dev]"

Configuration

🚀 Easiest path — no install required
A public hosted instance runs on Hugging Face Spaces. Point any MCP client at:
https://decaf-squirrel-arquivo-pt-mcp.hf.space/mcp
No Python, no pip install, no terminal. Just the URL. (See self-hosted setup below if you'd rather run it locally.)

Claude.ai (web or desktop) — Pro/Max/Team

The simplest setup for non-technical users.

Go to Settings → Connectors → Add custom connector.
Name: arquivo-pt
URL: https://decaf-squirrel-arquivo-pt-mcp.hf.space/mcp
Save. The six tools are now available in any new chat.

Claude Desktop

Edit your claude_desktop_config.json:

macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Windows: %APPDATA%\Claude\claude_desktop_config.json
Linux: ~/.config/Claude/claude_desktop_config.json

{
  "mcpServers": {
    "arquivo-pt": {
      "url": "https://decaf-squirrel-arquivo-pt-mcp.hf.space/mcp"
    }
  }
}

Restart Claude Desktop.

Claude Code (CLI)

One command:

claude mcp add --transport http arquivo-pt https://decaf-squirrel-arquivo-pt-mcp.hf.space/mcp

Cursor

Settings → MCP → Add server:

Name: arquivo-pt
URL: https://decaf-squirrel-arquivo-pt-mcp.hf.space/mcp

ChatGPT — Plus/Team/Enterprise

Settings → Connectors → Add → MCP server URL:

https://decaf-squirrel-arquivo-pt-mcp.hf.space/mcp

Other MCP clients (Zed, Cline, Windsurf, Continue, …)

Any client that speaks the MCP Streamable HTTP transport can use the same URL above. Refer to your client's docs for where to paste it.

Self-hosted setup

The hosted instance is fine for casual use, but it's a free shared CPU box with no SLA. Run it yourself if you need privacy, your own caching, or guaranteed availability.

As a local stdio server (Claude Desktop, Cursor, etc.):

{
  "mcpServers": {
    "arquivo-pt": {
      "command": "uvx",
      "args": ["arquivo-pt-mcp"]
    }
  }
}

uvx (from uv) auto-installs the package on first run — nothing to install manually beyond uv itself.

As a long-lived HTTP server:

pip install arquivo-pt-mcp        # or: uv add arquivo-pt-mcp
arquivo-pt-mcp --transport http --host 127.0.0.1 --port 8000

Then point your client at http://127.0.0.1:8000/mcp. To expose publicly, put it behind a TLS-terminating reverse proxy (Caddy, nginx, Traefik) and pass --allowed-host <hostname>.

Note: in HTTP mode the in-memory caches are shared across all connected clients.

Usage examples

Once connected, you can ask Claude things like:

“Search Arquivo.pt for ‘eleições 2005’ and show me the first three results.”
“Show me how publico.pt’s homepage looked on January 1, 2010.”
“How many times was expresso.pt archived in 2008?”
“Extract the text from the earliest snapshot of sapo.pt.”
”Search for archived images of Terreiro do Paço from before 2010.”
”Show me a screenshot of Público's homepage on Jan 1, 2010.”

API endpoints used

https://arquivo.pt/textsearch — text search
https://arquivo.pt/imagesearch — image search
https://arquivo.pt/wayback/cdx — capture index (CDX)
https://arquivo.pt/wayback/{timestamp}/{url} — snapshot retrieval
https://arquivo.pt/wayback/noFrame/{timestamp}/{url} — clean snapshot for text extraction
https://arquivo.pt/screenshot?url=... — PNG screenshot render
https://arquivo.pt/noFrame/replay/{timestamp}/{url} — frameless replay for screenshot

Official docs: https://github.com/arquivo/pwa-technologies/wiki/Arquivo.pt-API

Development

git clone https://github.com/thaenor/arquivo-pt-mcp.git
cd arquivo-pt-mcp
uv sync --extra dev
pytest -q

The project uses:

pytest + pytest-asyncio for testing
pytest-cov for coverage
ruff for linting and formatting

ruff check src tests
ruff format src tests
pytest --cov=arquivo_pt_mcp

Integration tests

Optionally, run integration tests against the live Arquivo.pt API:

RUN_INTEGRATION=1 pytest -m integration -v

These tests are marked with @pytest.mark.integration and skipped by default. They only run when the RUN_INTEGRATION=1 environment variable is set. On GitHub Actions they can be triggered manually via workflow_dispatch.

GitHub Actions note: Standard GitHub-hosted runners are US-based. Transatlantic TCP connectivity to arquivo.pt (hosted in Portugal) is sometimes unreliable — tests may fail with httpx.ConnectError or httpx.ConnectTimeout regardless of code quality. For this reason, the integration tests have been removed from the nightly CI schedule. They can still be triggered manually via workflow_dispatch when needed. When run locally from a European location the tests pass consistently.

Prémio Arquivo.pt

This project was built for the Prémio Arquivo.pt, a Portuguese contest that encourages the creation of tools and applications leveraging the Portuguese Web Archive for educational, scientific, cultural, and technical purposes.

Roadmap

Save Page Now — requires API credentials
TTL caching to reduce calls to Arquivo.pt
Rate-limit handling with exponential backoff
Input validation with Pydantic models
Advanced search by domain and collection
Integration with additional MCP clients (Zed, Cline, Windsurf)

License

MIT

Available Tools

6 tools

extract_textA

Fetch an archived snapshot and return its readable text content (HTML stripped).

ParametersJSON Schema

Name	Required	Description
`url`	Yes	URL to extract text from
`timestamp`	No	Optional: specific snapshot timestamp
`max_chars`	No

TDQS

A3.7/5.0

Behavior3/5

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

With no annotations, the description carries full burden. It discloses HTML stripping but does not mention error behavior, permission requirements, or return format. This is adequate but not rich.

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?

A single, front-loaded sentence that efficiently communicates the core action and outcome without extraneous words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the lack of output schema and annotations, the description is adequate for a simple retrieval tool but does not specify return format or error handling, leaving some gaps.

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?

The schema has 67% description coverage (missing max_chars description). The tool description adds no extra parameter information, so baseline score of 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?

The description clearly states the verb 'fetch', the resource 'archived snapshot', and the result 'readable text content (HTML stripped)'. It distinguishes from sibling tools like get_screenshot (image) and get_snapshot (possibly raw HTML).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage for archived web pages but does not explicitly state when to use this tool versus alternatives like get_snapshot or search. No when-not-to-use or alternative tool names are mentioned.

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

get_screenshotA

Get the Arquivo.pt PNG render of an archived page. By default returns the screenshot URL; pass inline=true to embed the PNG (useful for letting the model see the page). Omit timestamp for the latest capture.

ParametersJSON Schema

Name	Required	Description
`url`	Yes	URL to screenshot
`timestamp`	No	YYYY, YYYY-MM-DD, or YYYYMMDDHHMMSS
`inline`	No	Embed the PNG bytes in the response (heavier).
`max_bytes`	No	When inline=true, cap the embedded PNG size.

TDQS

A4.4/5.0

Behavior4/5

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

With no annotations, the description discloses default URL return, inline embedding, and timestamp behavior. It does not cover error cases or limitations, but the core behavior is clear.

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?

Two concise sentences front-load the main purpose and key options, with no redundant or misleading information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Adequately covers main functionality given the tool's simplicity and 100% schema coverage. Lacks return format details but not critical for a screenshot tool.

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 covers all parameters, but description adds value by explaining the default behavior (omit timestamp for latest) and the utility of inline (for model viewing).

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?

The description clearly states the tool gets a PNG render of an archived page from Arquivo.pt, differentiating it from sibling tools like get_snapshot by specifying PNG format and inline embedding option.

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?

Provides explicit guidance on using inline=true for embedding and omitting timestamp for latest capture. However, it does not mention when to use this tool over siblings like get_snapshot.

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

get_snapshotA

Get the archive URL for a specific snapshot of a page. Omit timestamp for the latest capture.

ParametersJSON Schema

Name	Required	Description	Default
`url`	Yes	URL to look up
`timestamp`	No	YYYY, YYYY-MM-DD, or YYYYMMDDHHMMSS

TDQS

A4.1/5.0

Behavior2/5

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

No annotations are provided, so the description must disclose behavioral traits. It only implies idempotency (getting a URL) but fails to mention read-only nature, rate limits, or error behavior (e.g., missing snapshot).

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?

Two sentences, front-loaded with purpose, no wasted words. Highly efficient.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

No output schema, but description mentions 'archive URL' which is sufficient. Minor gap: no mention of return format or error handling, but acceptable for a simple retrieval tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The description adds significant value beyond the input schema by noting that omitting timestamp fetches the latest capture. With 100% schema coverage, this additional guidance fully clarifies parameter usage.

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?

The description clearly states it retrieves the archive URL for a snapshot, and distinguishes by mentioning 'latest capture' option. It contrasts with siblings like get_screenshot or extract_text.

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?

Provides clear context for using the tool (getting snapshot archive URL) but does not explicitly state when not to use or compare to siblings. Omission of timestamp for latest capture is a usage hint.

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

image_searchB

Search 1.8B+ archived images on Arquivo.pt (Dionisius image search). Find historical photos, logos, and graphics from the Portuguese web.

ParametersJSON Schema

Name	Required	Description	Default
`query`	Yes	Image search terms
`max_items`	No
`from_date`	No	Start date: YYYY, YYYY-MM, or YYYY-MM-DD
`to_date`	No	End date: YYYY, YYYY-MM, or YYYY-MM-DD
`site_search`	No	Restrict to a domain
`image_type`	No	Image format: jpeg, png, gif
`size`	No	Image dimensions: small (≤65536 px²), medium, large (>810000 px²)
`safe_search`	No	NSFW filter; set to 'off' to disable. When off, pair with more=['safe'] to get the safe score (values <0.500 indicate unsafe).	on
`collection`	No	Restrict to a collection ID
`offset`	No	Pagination offset
`more`	No	Surface hidden fields: imgDigest (MD5 hash), pageHost (source host), pageImages (image count on page), safe (NSFW score 0.000-1.000, where <0.500 = unsafe)

TDQS

B3.1/5.0

Behavior2/5

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

No annotations are provided, so the description must disclose behavioral traits. It only states the tool searches an archive, but omits key aspects: pagination behavior, rate limits, authentication requirements, error handling, or side effects. The description adds minimal value beyond the tool's 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.

Conciseness4/5

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

The description is a single concise sentence with no wasted words. However, it lacks structural elements like bullet points or explicit breakdown of parameters and behavior. It is efficient but could be more informative without sacrificing brevity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given 11 parameters, no output schema, and no annotations, the description is insufficient. It does not explain return value format, pagination, date range semantics, or the effect of options like safe_search. The tool handles complex queries, but the description provides only a high-level overview.

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 coverage is 91%, so baseline is 3. The description does not elaborate on any parameter meanings beyond the schema. While it mentions the type of content, it does not clarify how parameters like query or date filters interact with the archive.

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?

The description clearly states the tool searches over 1.8 billion archived images on Arquivo.pt, specifying the types of content (historical photos, logos, graphics) and the scope (Portuguese web). This verb+resource combination effectively distinguishes it from sibling tools like search (text) or list_versions.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives (e.g., search, list_versions). It does not mention prerequisites, context, or when not to use it. The sole sentence implies a general use case but offers no comparative or exclusionary information.

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

list_versionsA

List every archived capture of a specific URL (CDX query). Use to see how a page changed over time.

ParametersJSON Schema

Name	Required	Description	Default
`url`	Yes	URL to query capture history for
`limit`	No
`offset`	No	Pagination offset for CDX results (skip first N captures)
`compact`	No	Return year-bucketed summary instead of full CDX records. Reduces output size for URLs with many captures.
`filter`	No	Field filters, repeatable. Format: '=field:value' (exact), '!=field:value' (negate+exact), '~field:regex' (regex), '!~field:regex' (negate+regex). Example: ['=status:200', '=mime:text/html']
`match_type`	No	URL matching: exact (default), prefix, host, or domain	exact
`from_date`	No	Start timestamp: YYYY, YYYY-MM, YYYY-MM-DD, or YYYYMMDDHHMMSS
`to_date`	No	End timestamp (same format as from_date)
`sort`	No	Sort order: default (chronological), reverse (newest first), closest (require 'closest' param)	default
`closest`	No	Timestamp for sort=closest to rank by time-distance. Accepts same date formats as from_date.

TDQS

A3.6/5.0

Behavior2/5

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

No annotations are provided, so the description must carry the burden. It only says 'List every archived capture' and 'CDX query,' which is minimal. It does not disclose pagination, sorting behavior, or what the output looks like, relying heavily on the schema which already provides some detail.

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?

Two sentences with no fluff. The first states the action and resource, the second provides a use case. Front-loaded and efficient.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With 10 parameters and no output schema, the description is too brief. It does not explain return format, pagination, or how to combine parameters for specific queries, leaving the agent to infer from schema alone.

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 coverage is high (90%), so baseline is 3. The description adds no parameter-specific meaning; all semantics are deferred to the parameter descriptions in the schema.

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?

The description clearly states the tool lists archived captures of a specific URL (CDX query) and provides a use case (seeing how a page changed over time). It distinguishes from siblings like get_snapshot or extract_text by focusing on listing historical versions.

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?

The description explicitly says 'Use to see how a page changed over time,' giving clear context for when to use it. It does not mention when not to use it or compare directly to siblings, but the purpose is well-defined.

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

searchA

Full-text search across the Portuguese Web Archive (Arquivo.pt). Use for finding pages that ever contained given terms, optionally scoped by date range or site.

ParametersJSON Schema

Name	Required	Description
`query`	Yes	Search terms
`max_items`	No
`from_date`	No	Start date: YYYY, YYYY-MM, or YYYY-MM-DD
`to_date`	No	End date: YYYY, YYYY-MM, or YYYY-MM-DD
`site_search`	No	Restrict to a domain, e.g. 'publico.pt'
`collection`	No	Restrict to a collection ID (e.g. 'EAWP33')
`mime_type`	No	Filter by MIME type: pdf, html, doc, xls, ppt, rtf
`offset`	No	Pagination offset. Use with next_page/previous_page from response to walk through results instead of fetching next_page URL via WebFetch.

TDQS

A3.8/5.0

Behavior3/5

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

No annotations are provided, so the description must carry the full behavioral burden. It describes a read-only search operation and mentions optional scoping, but does not detail pagination, rate limits, or result format. The behavior is implied but not fully disclosed.

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?

The description is a single concise sentence that front-loads the purpose. It has no wasted words, but could include a bit more detail without becoming verbose. It is appropriately sized for a search tool.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has 8 parameters and no output schema, the description provides a high-level overview but does not explain all filtering options or pagination behavior. The schema covers the details, but the description could mention additional filters like collection and mime_type. It is minimally complete.

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?

The schema coverage is high (88%), so the schema already explains most parameters. The description adds minimal value by mentioning date and site scoping but does not clarify parameters like 'max_items' or 'collection'. The description does not significantly enhance parameter understanding beyond the schema.

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?

The description clearly states the tool performs full-text search across the Portuguese Web Archive, specifying the verb 'search' and the resource 'Arquivo.pt'. It also distinguishes from sibling tools like 'extract_text' or 'get_screenshot' by focusing on search functionality.

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?

The description gives a clear use case: finding pages that ever contained given terms, with optional date or site scoping. Although it does not explicitly mention when not to use it or alternatives, the context of sibling tools helps differentiate. The guidance is adequate but lacks explicit exclusions.

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

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.9/5.0

Disambiguation5/5

Each tool has a clearly distinct purpose: text extraction, screenshot, snapshot URL, image search, version list, and full-text search. There is no overlap or ambiguity.

Naming Consistency3/5

Tool names mix patterns: 'extract_text', 'get_screenshot', 'get_snapshot', 'list_versions' follow verb_noun, but 'image_search' is noun_verb and 'search' is a single verb, reducing consistency.

Tool Count5/5

Six tools is an ideal count for an archive query server, covering the core operations without being too sparse or overwhelming.

Completeness4/5

The tools cover text, visual, URL, image search, version history, and full-text search. Minor gaps like metadata-only retrieval exist, but core workflows are well-supported.

Maintenance

ActivityInactive

ResponsivenessResponsive

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

mcp A
ai.llmse
Public MCP server for the LLM Search Engine
Search RAG Systems Developer Tools
102
mcp
dev.augments
Augments MCP Server - A comprehensive framework documentation provider for Claude Code
Developer Tools Documentation Access
2128
Keenable Web Search A
ai.keenable.api
Docs: https://docs.keenable.ai/mcp-server Keenable is a free, remote MCP server that gives agents access to the web index. Search the web with ranked results and date/site filters, then fetch any indexed page as clean markdown. Works out of the box with no account or API key.
Research & Data Search Web Scraping
23
UnifAPI
com.unifapi
Hosted MCP server for live public-data APIs and Skills for AI agents.
Open Data Search AI & Machine Learning
2

Related MCP Servers

Perplexity MCP Server
Search RAG Systems
RossH121
A
license
A
quality
D
maintenance
An MCP server that enables Claude to perform web searches using Perplexity's API with intelligent model selection based on query intent and support for domain and recency filtering.
Updated 3 months ago (2026-05-31 22:10 UTC)
6
4
MIT
Gemini Google Web Search MCP
Search Browser Automation RAG Systems
louxsye
A
license
B
quality
D
maintenance
An MCP server that enables AI models to perform Google Web searches using the Gemini API, complete with citations and grounding metadata for accurate information retrieval. It is compatible with Claude Desktop and other MCP clients for real-time web access.
Updated a year ago (2025-06-27 08:29 UTC)
1
3
Apache 2.0
mcp-server-wayback
Web Scraping Search Research & Data
lakshyamehta03
A
license
A
quality
C
maintenance
MCP 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.
Updated 3 months ago (2026-05-31 10:47 UTC)
6
3
MIT
raw-web-search
Search Web Scraping
andresfortunato
A
license
Not graded
quality
D
maintenance
An experimental MCP search server for Claude Code. Returns raw, verbatim web content instead of AI-rewritten summaries.
Updated 6 months ago (2026-03-18 18:35 UTC)
MIT

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/thaenor/arquivo-pt-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server