Skip to main content
Glama

Topic Trends Tracker: Google Trends Alternative, Real Numbers

topic_trends_tracker
Read-only

Compare public interest in topics, brands or people over time using Wikipedia pageview counts: absolute views, 30-day and year-over-year change, peaks and spikes, plus a 0-100 interest index.

Instructions

Compare public interest in topics, brands, products or people over time using real Wikipedia pageview counts: daily and monthly views, 30-day and year-over-year change, peaks, spike days, a trend label and a 0-100 interest index. Unlike Google Trends (relative 0-100 only) this reports absolute views; unlike podcast_leads_finder or company_hiring_signals it measures attention, not contacts. Use when you need to size or compare interest, spot spikes, or validate a topic. Do not use for search-keyword volume or social mentions (Wikipedia attention is a proxy), or for topics without a Wikipedia article (returned free as notFound). Parameters: each topic resolves to one article in the chosen language edition; pass a Wikipedia URL to pin an ambiguous name. months sets the window (data from July 2015); year-over-year is always computed. includeDailySeries adds a dailyViews array per row and makes output much larger; leave off unless charting. Returns per item: agentSummary, topic, article, url, interestIndex, trend (surging/rising/flat/falling), totalViews, avgDailyViews, last30dViews, change30dPct, yoyChangePct, peakDate, peakViews, spikes, monthlyViews, optional dailyViews.

Behavior: read-only; runs the Apify Actor pandadad0214/topic-trends-tracker (https://apify.com/pandadad0214/topic-trends-tracker) on your own Apify account. Price: $0.002 per topic tracked. Runs that find nothing are not charged per result, and spending is capped per call by run_max_charge_usd (default $0.50). run_max_items (default 50) limits items returned and fills maxTopics when you leave it unset, so it also limits what is billed; setting maxTopics higher can bill more than is returned. Most calls finish in 5-15 s for a few inputs; large inputs or crawls can take minutes, so raise run_timeout_secs (max 300) or shrink the input after a timeout error. Returns JSON {actor, count, items}; long text output is trimmed to whole items, with all items in structuredContent.

Input Schema

NameRequiredDescriptionDefault
deviceNoDevice. All devices (default), desktop only, or mobile web only. The mobile apps are included under All devices. Choices: all = All devices; desktop = Desktop only; mobile = Mobile web only.all
monthsNoHow many months back. Period to analyze, ending yesterday. 1 to 120 months (data starts July 2015); default 12. Year-over-year change is always computed when a year of history exists.
topicsNoTopics. One per line: a topic, brand, product, person, place or a Wikipedia link (https://en.wikipedia.org/wiki/ChatGPT). Each is matched to its Wikipedia article (redirects followed, e.g. Ozempic → Semaglutide). For ambiguous words like Mercury, paste the exact article link. Leave empty for a 3-topic demo.
languageNoWikipedia language. Language code of the Wikipedia edition to measure: en, de, fr, es, ja, pt, it, nl, pl… Default en. A full Wikipedia link overrides this per topic.en
maxTopicsNoMaximum topics. You pay per topic tracked, so this also caps the cost. 1 to 1,000; default 100.
excludeBotsNoCount people only (exclude bots and crawlers). On by default. Off counts every request, including automated ones.
run_max_itemsNoOptional. Most results to return from this call (default from PANDA_MAX_ITEMS, 50). Also limits how many results the Actor produces and charges for, unless you set its own max field.
run_timeout_secsNoOptional. Seconds to wait for results (default from PANDA_TIMEOUT_SECS, 120; max 300).
includeDailySeriesNoInclude the daily series in each dataset row. Adds a dailyViews array to every topic row (handy for charts via API). The daily numbers are always in the Excel and DAILY_CSV files either way.
run_max_charge_usdNoOptional. Hard spending cap for this call in USD (default from PANDA_MAX_CHARGE_USD, 0.50).

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.8/5.0
Behavior5/5

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

Beyond the annotations, the description discloses that the tool runs the Apify Actor pandadad0214/topic-trends-tracker on the caller's own Apify account, costs $0.002 per topic tracked, does not charge per result for empty finds, and has spending caps via run_max_charge_usd. It also describes typical runtime, timeout behavior, and the shape of returned JSON including structuredContent. This adds substantial operational context that the annotations do not provide.

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 long but appropriately front-loaded: it starts with what the tool does, then differentiates from alternatives, states exclusions, and explains parameters and behavior. The return-field list is dense but justified because there is no output schema. Some repetition between the description and schema prevents a perfect conciseness score, but the structure is clear and every major section serves a purpose.

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

Completeness5/5

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

Given the tool's complexity, ten parameters, lack of output schema, and actor-based execution model, the description is complete enough for an agent to call it correctly. It covers purpose, exclusions, alternatives, parameter interactions, cost controls, timeout behavior, and returned fields. No important operational or selection information appears to be 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 schema already documents all ten parameters well. The description still adds useful cross-parameter meaning, especially that run_max_items limits both returned items and billing while interacting with maxTopics, and that includeDailySeries materially increases output size. It also reinforces how topics resolve to Wikipedia articles and how URLs pin ambiguous names, though many individual parameter details remain primarily 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 states a specific verb and resource: compare public interest in topics, brands, products, or people over time using real Wikipedia pageview counts. It lists concrete outputs such as daily/monthly views, change metrics, peaks, spikes, trend labels, and an interest index, which distinguishes it from sibling lead-generation tools. It also explicitly positions itself against Google Trends and names attention-measurement alternatives, so an agent can identify the tool 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 Guidelines5/5

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

The description gives explicit positive use cases: sizing or comparing interest, spotting spikes, and validating a topic. It also gives clear exclusions: not for search-keyword volume, not for social mentions, and not for topics without a Wikipedia article, which are returned as notFound. It names alternative tools such as podcast_leads_finder and company_hiring_signals to clarify when another tool is more appropriate.

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