Skip to main content
Glama
kanto-labs

kanto-labs-mcp

Official
by kanto-labs
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Local

Get topic interest over time (coming soon)

get_topic_trends
Read-only

Measure and compare topic interest over time using Wikipedia pageviews. Get timelines, spikes, and trend direction for keywords to assess growth, seasonality, or breaking stories.

Instructions

COMING SOON: this Kanto Labs actor is not public on the Apify Store yet. Until it is, calls return an 'actor not yet public' error and nothing is charged. Measure and compare interest in topics over time, like Google Trends, from official Wikipedia pageview data (human traffic, 2015-07-01 to yesterday, CC0). Each keyword is matched to one Wikipedia article (exact title first, else the top non-disambiguation search hit; the matched article is returned so you can check it; write "Apple Inc." for the company, "apple" gives the fruit). Per topic: a daily, weekly or monthly timeline with absolute views and a 0-100 value normalised across all keywords of the call, total and average views, peak date, latest value, change percent and trend (rising/stable/falling), spike days, and interest by language edition. Use it for 'is interest in X growing?', comparing brands, products, people or technologies, seasonality, or finding the day a story broke. It counts people reading about a topic, not Google searches, and has no per-city data. About 5-10 s for 3 keywords and about a minute for 10 keywords over 12 months, so send up to about 30 keywords per call. Cost: $0.003 per topic analyzed, billed to your Apify account; keywords with no matching article are free. Runs the Apify actor kantolabs/wikipedia-trends with your APIFY_TOKEN; maxTotalChargeUsd caps the spend per call.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
endDateNoCustom end date, YYYY-MM-DD. Default yesterday (UTC).
keywordsYesTopics to compare on one scale: keywords ("bitcoin"), exact article titles ("Apple Inc.") or Wikipedia URLs.
languageNoWikipedia language edition used to match keywords: en (default), de, fr, es, ja, pt, it, ru, zh, pl, nl, ko...
platformNoDevices counted. Default all-access.
startDateNoCustom start date, YYYY-MM-DD (earliest 2015-07-01).
timeRangeNoPeriod to analyse. Default past90Days. "all" = 2015-07-01 to yesterday. Ignored when startDate or endDate is set.
granularityNoTimeline resolution. "auto" (default) = daily up to 3 months, weekly up to about 2 years, monthly beyond.
timeoutSecsNoGive up after this many seconds (max 300, Apify's limit for synchronous runs). Default 280. For big batches, split the input into several calls.
maxLanguagesNoHow many of the largest language editions to include. Default 10.
includeLanguagesNoAdd interest by language edition. Default true; false is faster.
includeRedirectsNoAdd views of titles that redirect to the article (old names, spellings) so a renamed topic does not start from zero. Default true.
maxTotalChargeUsdNoHard spending cap for this call in USD, enforced by Apify: the run stops once it has charged this much. Default 1 (server setting KANTO_MAX_CHARGE_USD).

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.2.0

TDQS

A4.6/5.0
Behavior5/5

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

Beyond the readOnlyHint annotation, it discloses that the actor is not yet public, calls currently return an actor-not-yet-public error and are not charged, billing is 0.003 per topic, unmatched keywords are free, runtime is roughly 5-10 seconds for 3 keywords and about a minute for 10, and maxTotalChargeUsd caps spend. This is excellent behavioral context that 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 dense and well organized: status warning, core function, matching rules, output summary, use cases, limitations, performance, and cost. The coming-soon warning is front-loaded, which is appropriate for an actor that currently returns an error. A few billing and runtime details could be tightened, so it is not a perfect 5.

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?

With no output schema, the description still summarizes the result shape: per-topic daily/weekly/monthly timeline, absolute views, normalized 0-100 value, totals, peak date, latest value, change percentage, trend, spike days, and language edition breakdown. It also covers data source, date range, matching, cost, runtime, current status, and limitations, making the definition complete enough for accurate selection and invocation.

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?

The schema already describes all 12 parameters, so the baseline is 3. The description adds genuinely useful semantics for keywords: each keyword is mapped to one article, exact title first, otherwise the top non-disambiguation hit, and the matched article is returned. It also adds operational guidance like sending up to about 30 keywords per call despite the schema allowing 50.

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 action and resource: measure and compare interest in topics over time from Wikipedia pageview data. It also distinguishes itself from the likely sibling get_trending_topics by emphasizing historical timelines and positioning the tool as Google Trends for Wikipedia. 'Over time' clearly separates it from a simple current-trends tool.

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?

It gives explicit use cases such as checking whether interest in X is growing, comparing brands/products/people, seasonality, and finding when a story broke. It also states what this tool is not: it counts pageviews, not Google searches, and has no per-city data. It does not explicitly name a sibling alternative for current trending topics, 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