Wikipedia page view trend data for AI

Trends MCP returns English Wikipedia article pageviews as a weekly series on a 0-100 index, with about 5 years of history. The keyword is the article title, not a Google query and not a Wikidata Q-id. For news-driven names, views often move 24-72 hours before search fully reacts. The same MCP connection covers 25+ sources, so pageviews can sit next to Google Trends and news sentiment. The free plan includes 100 requests per month. Starter is $19/month.

How Wikipedia pageviews work as a trend source

Wikimedia publishes pageview counts for article titles. Trends MCP stores those counts, rescales the window so the peak is 100, and returns a series an assistant can plot or difference. A needle spike is almost always a news, sports, or awards event. A staircase higher over years is usually a subject entering curricula, professional licensing, or lasting public debate.

Pageviews measure curiosity, not agreement. A scandal and a scientific breakthrough can produce similar spikes. Tone belongs on the news sentiment source. Wikipedia answers "how many people opened the explainer."

get_trends is the history call. get_growth turns the same series into 1M or 3M percentages for screening. get_top_trends with type Wikipedia Trending needs no article title; it is the live "what articles are moving" feed.

Article title as the keyword

The keyword should match the English article title: Quantum computing, Tesla, Inc., 2024 Summer Olympics. Loose phrases that would work on Google (tesla stock) often miss because no article uses that exact title. Disambiguation pages (Mercury) are the wrong target; the assistant should use Mercury (planet) or Mercury (element) as they appear in the encyclopedia.

Redirects sometimes still resolve, but the durable habit is the canonical title after any redirect. Person names should follow the article, including disambiguator parentheses when Wikipedia uses them. Company articles often include a legal suffix or , Inc. that a ticker symbol will not match.

Topics without an English article cannot produce a series. That is a feature for event detection: a sudden article creation plus a view spike is itself a signal, visible on the live Wikipedia Trending feed before a long weekly history exists.

Native Wikimedia APIs versus a trend index

The Wikimedia REST and Pageviews APIs are public and well documented. They return raw counts per article and per calendar day, with project and access filters. Building a 5-year weekly index, aligning it to Google's 0-100 scale, and calling it from Claude or Cursor still means writing a client, handling rate windows, and joining other platforms separately.

Trends MCP does not replace dump processing, category crawls, or edit-history research. It returns one normalized pageview series inside a session that already queries shopping, video, and social sources. Research teams that need project-level filters (mobile vs desktop, all-access vs user) should keep the Wikimedia APIs for that granularity and keep Trends MCP for cross-source comparison.

A second difference is live ranking. Wikimedia has related tools for top viewed pages by day. Trends MCP exposes that job as get_top_trends with a stable feed name, next to Amazon bestsellers and Google News, so an agent does not learn a separate HTTP dialect per platform.

Who uses article-level pageviews

Newsrooms watch politician, company, and disaster articles as a curiosity meter that is harder to buy than social impressions. Equity researchers watch issuer articles around filings, then confirm with news volume so a Wikipedia spike is not mistaken for buying. Educators and publishers watch concept pages (inflation, CRISPR) as a slow demand curve for explainers. Crisis communicators watch the company article during an incident because journalists and the public both land there first.

The Wikipedia page views companion page covers adjacent pageview workflows. This source page is the MCP contract: title in, weekly index out.

Sporting events and awards nights produce some of the cleanest spikes: a person or club article jumps for 48 hours, then returns to the baseline. Those spikes are real curiosity and still a poor investment thesis by themselves. The useful follow-up is whether the article's weekly series stays elevated a month later, which is the difference between a broadcast night and a lasting public figure.

Limits and caveats

English only. Mobile and desktop are not split in the Trends MCP series. Automated traffic and school assignments can inflate educational articles on a calendar. The 0-100 index is relative to that article's own peak; a local mayor at 100 is not "more famous than" a country article at 30 in a quiet week.

Short-lived events may need data_mode='daily' on a 30-day window. A 5-year weekly chart will hide a 48-hour spike inside one point. After the event, the weekly chart is the right object for "did curiosity persist."

Quota is 100 requests per month on the free plan, $19/month on Starter. Scanning every article in a category every hour is a Wikimedia-API job, not a Trends MCP job.

Comparison: Wikipedia curiosity data

Trends MCP is one MCP connection covering 25+ sources. Wikipedia pageviews arrive already aligned to the same 0-100 index as search and shopping, with about 5 years of weekly history.

Wikimedia Pageviews API remains the path for raw daily counts, project filters, and research that must cite the primary dump. It does not by itself join Amazon or TikTok.

Enterprise media suites sometimes include Wikipedia as a mention source. That is still media monitoring, not a portable pageview index. Teams should check current vendor pricing for those suites. Trends MCP is the assistant-facing pageview series, not a newsroom CMS.