News Site Article Archive MCP Server

Collect articles from news sites by date range

collect_news_site_articles

Read-onlyIdempotent

Retrieve full articles published by named news sites within a past date range, including text, title, author, date, and section, using sitemaps with Internet Archive fallback for missing pages.

Instructions

Find the articles a named news site published in a past date range, from its sitemaps and the Internet Archive capture index, and return full text, published date, title, author, and section. Paywalled and refused pages return a free row with no text. No browser, so sites built by JavaScript return little. Pay per event on Apify: 0.003 USD per article.

Input Schema

Name	Required	Description
`sites`	No	News sites by domain, for example techcrunch.com, up to 20.
`date_to`	No	The latest published date, as YYYY-MM-DD. Default: today.
`date_from`	No	The earliest published date, as YYYY-MM-DD. Default: 30 days before Date to.
`min_words`	No	Pages with fewer words are not counted as articles and are free. Default 80.
`obey_robots`	No	yes (default): pages robots.txt disallows are skipped and counted. no: read them anyway.
`url_contains`	No	Optional. Keep only addresses with any of these texts, for example /politics/.
`max_charge_usd`	No	Optional. The run stops before a charge that would pass this amount. Summary rows are always returned.
`use_archive_copy`	No	yes (default): a page the site answers with 404, 410, 500, 502, or 504 is read from the Internet Archive, at the archived row price. Refused and paywalled pages are never read from an archive. no: gone pages return a free row.
`use_archive_index`	No	yes (default): when the sitemaps run out, also find addresses in the Internet Archive capture index, which reaches years that sitemaps no longer list. no: sitemaps only.
`max_articles_per_site`	No	Articles to return from each site, up to 5,000. Default 100.

Schema Changelog

Changes observed during successful MCP inspections.

First observedv1.0.0Nov 9, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Beyond the readOnly/idempotent annotations, the description discloses the failure modes that matter: paywalled and refused pages yield a free row with no text, JS-built sites yield little, and pricing is 0.003 USD per article on Apify. It also explains the cost-control mechanism (summary rows always returned, runs stop before a charge). This is behavior an agent could not infer from annotations.

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?

Four sentences, front-loaded with purpose, then limitations, then cost. No filler, no restatement of the title, and each sentence carries distinct information an agent needs.

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?

For a 10-parameter, no-required-parameter, no-output-schema tool, the description covers purpose, return fields, failure modes, and cost, which is most of what an agent needs. It could say more about default volume (max_articles_per_site default 100) and how the archive flags interact, but nothing essential is missing.

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

Parameters4/5

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

Schema coverage is 100%, so the baseline is 3, but the description adds economics and semantics the schema does not: the per-article price that makes max_charge_usd meaningful, and the fact that below-min_words pages are free. It does not explain the interaction between the two archive flags or the per-site cap, leaving some parameter interpretation to 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 opens with a specific verb and resource ("Find the articles a named news site published in a past date range") and names both retrieval channels (sitemaps, Internet Archive capture index). It also enumerates the returned fields (full text, published date, title, author, section), so an agent knows exactly what it gets without opening the schema.

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?

Usage context is clear: date-range article harvesting from a named domain, with explicit exclusions about where it fails ("No browser, so sites built by JavaScript return little"). There are no sibling tools to route against, and no explicit statement of when not to use it beyond the JS caveat, so it stops short of a 5.

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

Deploy Server

Other Tools

collect_news_site_articlesA