Trend data from Google Trends, YouTube, TikTok, Reddit, Amazon, Wikipedia, npm, Steam and more
Scored across 4 tools
Each tool targets a clearly distinct data type: growth metrics, full time series, top posts for a hashtag, and top-trending boards. The tools cross-reference each other (e.g., get_growth points to get_time_series, get_top_posts points to get_top_trends), which further reinforces their boundaries.
All tools follow a consistent 'get_' verb prefix followed by a noun describing the resource: growth, time_series, top_posts, top_trends. The naming pattern is uniform and predictable, even with the server-specific prefix.
Four tools is a reasonable, focused set for a trends API covering both historical analytics and live boards. It is slightly lean but each tool earns its place with no redundancy or bloat.
The set covers keyword growth, full time series, top posts, and top-trending boards, which are the core needs for trend analysis. A minor gap is the lack of a tool to discover available sources, categories, or feed types, but agents can infer these from tool descriptions.
Point-to-point growth for a keyword on one or more sources. Each window is a preset string (12M, 3M, YTD, and the other listed periods). Values are on a 0-100 scale, plus absolute volume when available. Designed for growth questions; for charting or custom math, get_time_series provides the full series. app downloads and app rankings are keyword sources (Android bundle ID). They are not the App Store / Google Play live boards on get_top_trends. Returns a plan-limit message when the request is rate limited or the monthly quota is used up.
| Name | Required | Description | Default |
|---|---|---|---|
| source | Yes | One source, or comma-separated sources (e.g. 'amazon, tiktok, youtube'). Valid: 'google search', 'google images', 'google news', 'google shopping', 'youtube', 'wikipedia', 'tiktok', 'reddit', 'amazon', 'news sentiment', 'news volume', 'npm', 'python', 'steam', 'app downloads', 'app rankings'. | |
| keyword | Yes | What to look up. The string format is required by source. Standard sources (google search, google images, google news, google shopping, youtube, wikipedia, tiktok, reddit, amazon, news sentiment, news volume): any name or phrase, e.g. 'nike'. npm: exact npmjs.com package name, case-sensitive. Right: 'react', '@babel/core'. Wrong: 'React', 'React.js'. python: exact PyPI project name. Right: 'pandas', 'requests'. Wrong: 'Pandas'. steam: game display name in plain English, not a Steam App ID. Right: 'Elden Ring', 'CS2'. First Steam store search result wins, so use an unambiguous name. app downloads and app rankings: Android bundle ID only (the id= value on Google Play). Right: 'com.openai.chatgpt', 'com.whatsapp'. Wrong: 'ChatGPT', 'WhatsApp', an iOS App Store ID, or a bundle ID that is not Android. Find it at play.google.com/store/apps/details?id=THIS_PART. If the request includes app downloads or app rankings with other sources, keyword must still be the Android bundle ID. | |
| percent_growth | No | Growth windows. Default if omitted: ['12M']. Each item must be a preset string: '7D', '1W', '14D', '2W', '30D', '1M', '2M', '3M', '6M', '9M', '12M', '1Y', '18M', '24M', '2Y', '36M', '3Y', '48M', '4Y', '60M', '5Y', 'MTD', 'QTD', 'YTD'. Every preset is a two-date comparison. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds value beyond these: it specifies the 0-100 scale, availability of absolute volume, and the plan-limit message on rate limiting/quota exhaustion. It also clarifies the keyword format constraints for special sources, which is behavioral context not in annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficient, with every sentence serving a purpose: it defines the tool, explains the value scale, differentiates from siblings, clarifies special source keyword rules, and discloses rate-limit behavior. It is well-structured, front-loading the core purpose and then addressing edge cases. No filler or redundant text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (3 params, all documented), no output schema, and rich annotations, the description is complete. It covers the return scale, absolute volume, plan-limit errors, source-specific keyword requirements, and the exact preset window list (implicitly via schema but reinforced). An agent has everything needed to call it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with detailed descriptions, so baseline is 3. The tool description adds substantial meaning: it explains the source-specific keyword formats (npm exact package names, PyPI exact names, Steam display names, Android bundle IDs), provides concrete examples and wrong usages, and clarifies the rule when mixing app sources with others. This goes well beyond the schema's generic descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool computes point-to-point growth for a keyword on one or more sources, with specific details on value scale (0-100) and absolute volume. It explicitly distinguishes from siblings: get_time_series for charting/custom math and get_top_trends for live boards, so an agent can immediately identify the right tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives explicit when-to-use guidance: 'Designed for growth questions' and directs to get_time_series for charting or custom math. It also clarifies that app downloads/rankings are not the live boards on get_top_trends, preventing confusion. Rate-limit and quota behavior is disclosed, which is operational guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Full historical series for one keyword and one source (0-100 values, plus volume when available). Suited for charting or custom math. Live 'what's trending now' boards are on get_top_trends. get_growth answers most growth questions with less data. Returns a plan-limit message when the request is rate limited or the monthly quota is used up.
| Name | Required | Description | Default |
|---|---|---|---|
| source | Yes | Exactly one source per request. Valid: 'google search', 'google images', 'google news', 'google shopping', 'youtube', 'wikipedia', 'tiktok', 'reddit', 'amazon', 'news sentiment', 'news volume', 'npm', 'python', 'steam', 'app downloads', 'app rankings'. | |
| keyword | Yes | What to look up. The string format is required by source. Standard sources (google search, google images, google news, google shopping, youtube, wikipedia, tiktok, reddit, amazon, news sentiment, news volume): any name or phrase, e.g. 'tesla'. npm: exact npmjs.com package name, case-sensitive. Right: 'react', '@babel/core'. Wrong: 'React', 'React.js'. python: exact PyPI project name. Right: 'pandas', 'requests'. Wrong: 'Pandas'. steam: game display name in plain English, not a Steam App ID. Right: 'Elden Ring', 'CS2'. First Steam store search result wins, so use an unambiguous name. app downloads and app rankings: Android bundle ID only (the id= value on Google Play). Right: 'com.openai.chatgpt', 'com.whatsapp'. Wrong: 'ChatGPT', 'WhatsApp', an iOS App Store ID, or a bundle ID that is not Android. Find it at play.google.com/store/apps/details?id=THIS_PART. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish read-only, idempotent, non-destructive behavior. The description adds useful non-annotation behavior: the 0-100 value range, optional volume data, and the plan-limit message on rate limiting or quota exhaustion.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Four sentences, each earning its place: purpose, use case, sibling alternatives, and error behavior. The most important information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 2-parameter read-only tool with a fully documented schema, the description covers the main return characteristics, error/limit behavior, and alternatives. It does not describe the exact output structure, but no output schema exists and the description gives enough shape (0-100 values plus optional volume).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the source and keyword properties are already richly documented. The description mentions 'one keyword and one source' but adds no meaning beyond what the schema already provides, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb-resource relationship: it returns the full historical series for one keyword and one source. It also distinguishes itself from siblings by explicitly routing live boards to get_top_trends and growth questions to get_growth.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives concrete usage context ('Suited for charting or custom math'), names an alternative for live data, and points to get_growth for most growth questions. This is explicit enough for an agent to choose between tools without opening schemas.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Live top posts for one hashtag on one social source. Fetched live on every call; nothing is stored. For when the user already has a hashtag and wants the posts winning on it. get_top_trends ranks the hashtags themselves. Returns a plan-limit message when the request is rate limited or the monthly quota is used up.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max posts to return. Default 20, min 1, max 20. | |
| source | Yes | Exactly one source per request. Valid: 'tiktok', 'instagram'. | |
| keyword | Yes | The hashtag, with or without '#'. Spaces are removed. Example: 'bookstagram' or '#fitness'. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the tool as read-only, idempotent, open-world, and non-destructive. The description adds valuable behavioral context beyond that: data is fetched live on every call, nothing is stored, and a plan-limit message is returned on rate limiting or quota exhaustion. No contradiction exists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Four short sentences, each earning its place: the core purpose, live-fetch behavior, usage context, the sibling differentiator, and the rate-limit behavior. Information is front-loaded and no words are wasted.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple three-parameter read-only tool with no output schema, this description is complete enough for an agent to select and invoke it correctly. It covers when to use it, what it returns conceptually ('top posts'), live behavior, storage, and error signaling. The missing structured return details are not necessary for invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with clear parameter documentation for keyword normalization, valid sources, and the limit bounds/default. The description adds broader context about one hashtag and one source but does not meaningfully enrich individual parameter semantics beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb-resource pair: 'Live top posts for one hashtag on one social source.' It clearly distinguishes itself from the sibling by stating 'get_top_trends ranks the hashtags themselves,' so an agent can tell the two tools apart.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use the tool: 'when the user already has a hashtag and wants the posts winning on it.' It also names the closest alternative and what that tool does instead, giving clear selection guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Live top-trending board for exactly one feed type. No keyword. For 'Amazon Best Sellers by Category', 'Google Trends by Category', 'Top Websites', 'Substack by Category', and 'TikTok Trending Hashtags by Category', category selects the board. Default sort is current rank. Use sort='rank_change' for climbers vs a prior snapshot (window 1d, 3d, 7d, 14d, or 30d). If the requested board is not in the database yet (for example a country that is not collected on the schedule), the board is fetched live. App Store Top Free, App Store Top Paid, and Google Play are live store boards, not keyword lookups. App history is available via get_growth or get_time_series with source app downloads or app rankings and an Android bundle ID. Live boards are only available here, not via get_time_series. Returns a plan-limit message when the request is rate limited or the monthly quota is used up.
| Name | Required | Description | Default |
|---|---|---|---|
| sort | No | How to rank the board. 'rank' (default): current leaders. 'rank_change': biggest climbers vs a prior snapshot. Mover rows include rank, keyword, prev_rank, and rank_change. | |
| type | Yes | Exactly one live feed. Valid: 'Amazon Best Sellers Top Rated', 'Amazon Best Sellers by Category', 'App Store Top Free', 'App Store Top Paid', 'GitHub', 'Google News Top News', 'Google Play', 'Google Trends', 'Google Trends by Category', 'IMDb MOVIEmeter', 'Open Library Trending Books', 'Reddit Hot Posts', 'Reddit World News', 'Top Websites', 'Spotify Top Podcasts', 'Steam Most Played', 'Substack', 'Substack by Category', 'TikTok Trending Hashtags', 'TikTok Trending Hashtags by Category', 'TikTok Trending Searches', 'Wikipedia Trending', 'X (Twitter) Trending', 'YouTube Trending'. | |
| limit | No | Max rows to return. Default 25, min 1, max 200. | |
| offset | No | Rows to skip for pagination. Default 0. | |
| window | No | Lookback used only when sort is 'rank_change'. One of '1d', '3d', '7d', '14d', '30d'. Default '30d'. Short windows only work on daily feeds; weekly and monthly feeds return a note pointing to a longer window. | |
| country | No | Optional ISO 3166-1 alpha-2 code (US, GB, JP). Aliases like 'USA' or 'United States' resolve to US. Omit for the default US board. Only for Google Trends, Google Trends by Category, YouTube Trending, TikTok Trending Hashtags, TikTok Trending Hashtags by Category, and X (Twitter) Trending. | |
| category | No | Pass this whenever type is 'Amazon Best Sellers by Category', 'Google Trends by Category', 'Top Websites', 'Substack by Category', or 'TikTok Trending Hashtags by Category'. Use the official name. Without it those feeds mix every board. Only omit on a first pull to learn the official names. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnly/idempotent annotations, the description discloses meaningful behavior: boards not yet in the database are fetched live, App Store and Google Play boards are live store boards rather than keyword lookups, and rate-limited or quota-exceeded requests return a plan-limit message. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but every sentence earns its place: purpose is front-loaded, then category behavior, sort/window semantics, live-fetch behavior, sibling alternatives, and a rate-limit note. No filler or repetition of the schema's enums.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex tool with seven parameters and no output schema, the description covers the key operational details an agent needs: feed type restrictions, category requirements, sort and window behavior, live fetching, alternative tools for history, and rate-limit response behavior. Nothing critical is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already documents all seven parameters thoroughly, so the bar is high. The description adds useful parameter-adjacent context about `sort`/`window` semantics, the role of `category` in selecting boards, and the fact that some types are live store boards rather than keyword lookups, though much of it echoes the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific operation: return the live top-trending board for exactly one feed type, with no keyword. It also clarifies which feed types require a category and distinguishes this tool from history-style siblings by noting live boards are only available here, not via get_time_series.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides explicit when-to-use guidance: use category for specific board types, use sort='rank_change' for climbers over a window, and use get_growth or get_time_series for app history. It also states a clear when-not: live boards are not available via get_time_series.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
trends___get_top_poststrends___get_growthtrends___get_time_seriestrends___get_top_trendsTrend data from Google, TikTok, Amazon, Reddit, YouTube, Steam, npm and more as JSON
Cross-platform social trend signals from TikTok, YouTube, Reddit and X. Free key at trendsapi.ai
Find rising topics before they peak across search and social. Free key at trendsapi.ai
YouTube transcripts (video, channel, search), Google Trends, Google Play and App Store reviews.
Add one secure layer between your agents and this server.