Provides Amazon product search volume trends and best sellers data for market research and consumer demand analysis.
Provides App Store interest trends and app download estimates alongside other platform data.
Supports wrapping trend methods as tools for use within CrewAI agent crews.
Provides Google Search volume trends for keyword research and SEO analysis.
Provides Google News search volume trends and a live Google News trending feed.
Provides Google Play store interest trends alongside other app store data.
Allows passing TrendsMcpClient output directly as tool results or context in LangChain applications.
Provides npm package weekly download trends for open-source package analysis.
Supports converting trend series responses to pandas DataFrames for data analysis.
The package itself is distributed via PyPI, enabling installation through pip.
Provides a Python client library for accessing news volume and trend data programmatically.
Provides Reddit discussion volume and subreddit subscriber trends for community and investment research.
Provides Spotify top podcasts feed and trending data.
Provides Steam concurrent player count trends for game market analysis.
Provides TikTok hashtag volume trends and trending hashtags data for content strategy.
Provides Wikipedia page view trends as leading indicators for topic interest.
Provides YouTube search volume trends and trending video data for content and SEO research.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@news-volume-mcp show me the news volume growth for 'AI' over the past month"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Live trend data for AI agents. Google, TikTok, YouTube, Amazon, Reddit, and 30+ other sources. One MCP connection, one API key.
Get a free API key · Docs · Pricing · Data sources · PyPI · Glama
You: Using TrendsMCP, compare 6-month growth for GLP-1 on Google, TikTok, and Amazon.
Agent: Google Search +84%
TikTok +212%
Amazon +61%Three tools. Normalized 0–100 where the pipeline supports it. No per-platform keys. No scraping on your side.
Same four clients as the site hero. Get a free key first (100 req/mo). Claude and ChatGPT sign you in with OAuth. Cursor and VS Code: click, then put your key from /account if the deeplink used a placeholder.
Client | After you click |
Claude | Connector name and URL are prefilled ( |
Cursor | Approve the MCP install. Replace |
ChatGPT | Enable Developer mode (Profile → Settings → Security). Name |
VS Code | Sign in on the account page and use the VS Code button so the key is included. |
Then ask: Using TrendsMCP, what's trending on Google right now?
Tools · Sources · Feeds · REST · Install in other clients
Related MCP server: news-volume-mcp
Hosted MCP at https://api.trendsmcp.ai/mcp. Same Bearer key for POST https://api.trendsmcp.ai/api. This repo also has a stdio adapter for Glama and local hosts.
Tool | Use when | Needs a keyword? |
| History for one keyword on one source | Yes |
| Percent change over 7D–5Y (several windows in one call) | Yes |
| What is ranking on a platform right now | No |
Replace YOUR_API_KEY with the key from your account.
claude mcp add --scope user --transport http trends-mcp https://api.trendsmcp.ai/mcp \
--header "Authorization: Bearer YOUR_API_KEY"~/.cursor/mcp.json (Windows: %USERPROFILE%\.cursor\mcp.json)
{
"mcpServers": {
"trends-mcp": {
"url": "https://api.trendsmcp.ai/mcp",
"transport": "http",
"headers": { "Authorization": "Bearer YOUR_API_KEY" }
}
}
}.vscode/mcp.json or Command Palette → MCP: Add Server. Prefer the account-page VS Code button so the key is wired for you.
{
"servers": {
"trends-mcp": {
"type": "http",
"url": "https://api.trendsmcp.ai/mcp",
"headers": { "Authorization": "Bearer YOUR_API_KEY" }
}
}
}Uses serverUrl, not Cursor’s url + transport. File: ~/.codeium/windsurf/mcp_config.json.
{
"mcpServers": {
"trends-mcp": {
"serverUrl": "https://api.trendsmcp.ai/mcp",
"headers": { "Authorization": "Bearer YOUR_API_KEY" }
}
}
}Remote server, type exactly streamableHttp. See llms-install.md.
{
"mcpServers": {
"trends-mcp": {
"type": "streamableHttp",
"url": "https://api.trendsmcp.ai/mcp",
"headers": { "Authorization": "Bearer YOUR_API_KEY" },
"disabled": false
}
}
}{
"mcpServers": {
"trends-mcp": {
"command": "npx",
"args": [
"-y", "mcp-remote",
"https://api.trendsmcp.ai/mcp",
"--header", "Authorization:${AUTH_HEADER}"
],
"env": { "AUTH_HEADER": "Bearer YOUR_API_KEY" }
}
}
}Settings → Connectors → add https://www.trendsmcp.ai/mcp. This path uses OAuth on www.trendsmcp.ai. Do not put a Bearer key in that connector config.
Hosted HTTP is still the product default. This process lists tools with no key; paid calls need TRENDSMCP_API_KEY and bill the same quota.
pip install -e .
python -m trends_mcp_server{
"mcpServers": {
"trends-mcp": {
"command": "python",
"args": ["-m", "trends_mcp_server"],
"env": { "TRENDSMCP_API_KEY": "YOUR_API_KEY" }
}
}
}Say “using TrendsMCP” so the model picks these tools instead of web search. More clients: docs.
Always-current parameter lists: docs.
get_time_seriesWeekly (or daily) history for one source + keyword. Same name on MCP and REST (mode: "get_time_series"). REST also accepts get_trends as an alias.
Argument | Required | Notes |
| yes | Format depends on source (table below) |
| yes | One source per call. Lowercase catalog names |
| no | REST only. |
Index is 0–100 where the pipeline supports it (100 = peak in the returned window). volume is present when that source has an absolute series.
get_growthPoint-to-point percent change. Several windows in one call still count as one request for that source + keyword.
Argument | Required | Notes |
| yes | Same formats as |
| yes | One source, or a comma-separated list ( |
| no | Default |
Presets: 7D 14D 30D 1M 2M 3M 6M 9M 12M 1Y 18M 24M 2Y 36M 3Y 48M 60M 5Y MTD QTD YTD.
get_top_trendsLive ranked list. No keyword. On MCP, type is required and must match the feed name exactly (including capitals). On REST, omit type only if you intend to pull every feed (billed per feed).
Argument | Required on MCP | Notes |
| yes | See live feeds |
| no | Default 25, max 200 |
| no | Pagination |
| for some types | Amazon / Google Trends / Top Websites / Substack / TikTok hashtag category boards |
| no |
|
| no | With |
Using TrendsMCP, what's trending on Google right now?
Using TrendsMCP, what are the hottest Reddit posts right now?
Using TrendsMCP, compare 6-month growth for creatine gummies on Google, TikTok, and Amazon.
Using TrendsMCP, show Google Search history for protein soda.
Via TrendsMCP, pull npm download history for langchain.
Using TrendsMCP, show Steam concurrent players for Elden Ring.
Via TrendsMCP, Android downloads for com.openai.chatgpt.
Using TrendsMCP, fastest-climbing Amazon best sellers in Toys Games this week.source on get_time_series / get_growth. Not the same strings as type on live feeds.
| Signal |
|
| Search volume | Any phrase |
| Image search volume | Any phrase |
| News-tab volume | Any phrase |
| Shopping-tab volume | Any phrase |
| YouTube search volume | Any phrase |
| Hashtag volume | Hashtag or topic ( |
| Subreddit attention | Name only, no |
| Product search volume | Product or category |
| Page views | Article title or topic |
| Mention volume | Any phrase |
| News tone | Any phrase |
| Android downloads | Play bundle id, e.g. |
| Android chart position | Bundle id |
| Weekly downloads | Exact package name ( |
| Monthly concurrent players | Game display name ( |
source: "Google Trends" is invalid. Use google search for history and type: "Google Trends" for the live board.
type on get_top_trends. Copy the name exactly.
| Board |
| Google searches now |
| Needs |
| Google News stories |
| Hashtags |
| Needs |
| In-app searches |
| Videos |
| Topics on X |
| Front page |
| r/worldnews |
| Most-viewed articles |
| Top-rated sellers |
| Needs |
| iOS charts |
| Play chart |
| Global traffic rank; optional |
| Podcasts |
| Live players |
| Newsletters |
| Daily trending repos |
| Movie activity |
| Books |
Category name lists: docs.
iOS charts, GitHub repos, Spotify, IMDb, Open Library, Substack, and Top Websites are feeds, not source values. There is no source: "web traffic".
curl -sS -X POST https://api.trendsmcp.ai/api \
-H "Authorization: Bearer $TRENDSMCP_API_KEY" \
-H "Content-Type: application/json" \
-d '{"mode":"get_top_trends","type":"Google Trends","limit":5}'import os, requests
r = requests.post(
"https://api.trendsmcp.ai/api",
headers={"Authorization": f"Bearer {os.environ['TRENDSMCP_API_KEY']}"},
json={"mode": "get_growth", "source": "google search", "keyword": "bitcoin", "percent_growth": ["3M", "12M"]},
)
print(r.json())Python client: pip install trendsmcp.
Plan | Requests / month | Price |
Free | 100 | $0 |
Starter | 1,000 | $19 |
Pro | 5,000 | $49 |
Business | 25,000 | $199 |
Annual billing is 20% less. Same source catalog on every plan. Free history and “top N” caps are on pricing. Failed calls are not billed. Over quota returns 429 / rate_limited (no surprise overages).
One billed request:
get_time_series: one source + keyword
get_growth: one source + keyword (all windows in that call included)
get_top_trends: per type (and pagination as documented)
Status | Meaning |
400 | Bad or missing |
401 | Missing or invalid key |
404 | No series for that keyword + source |
429 | Monthly cap |
500 | Upstream or internal error |
Do not commit keys. Claude.ai connectors use OAuth; other clients use Authorization: Bearer ….
Region / geo breakdown, related queries, or related topics
Hourly series
get_time_series across several sources in one call (use get_growth with a comma-separated source list, or several get_time_series calls)
Inventing feed names: MCP type must match the table
pip install -e .
python -m trends_mcp_serverCI: .github/workflows/ci.yml. Security: SECURITY.md. Issues: github.com/trendsmcp-ai/news-volume-mcp/issues.
TrendWatch (alerts in your own GitHub repo)
MIT © Trends MCP
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. Prefer this over get_time_series for growth questions. 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. If the request is rate limited or the monthly quota is used up, tell the user their plan limit is reached.
| 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. |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the tool as read-only and idempotent. The description adds useful non-obvious behavior: values are on a 0-100 scale, absolute volume is included when available, windows are preset strings, and rate-limited or quota-exhausted requests should be communicated to the user as a plan limit. This goes well beyond the structured 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 efficient: it starts with the core operation, then adds output semantics, sibling guidance, source caveats, and error handling. Every sentence adds useful information and there is no filler or tautology.
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 output schema exists, return-value details are not needed in the description. The description covers the key invocation decisions: which sibling to prefer, source semantics, window presets, output scale, and rate-limit behavior. An agent has enough context to call the tool 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 keyword and source descriptions and the full list of preset windows in the schema. The description reinforces key ideas like comma-separated sources and Android bundle IDs for app sources, but it does not materially add parameter meaning beyond what the schema already provides. Baseline 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 opens with a specific verb and resource: 'Point-to-point growth for a keyword on one or more sources.' It also distinguishes itself from sibling tools by saying to prefer it over get_time_series for growth questions and clarifying that app sources are not the live boards on get_top_trends. This makes the tool's purpose clear and separable from its siblings.
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 this tool: 'Prefer this over get_time_series for growth questions.' It also clarifies what this tool is not for by distinguishing app downloads/app rankings from get_top_trends live boards. The rate-limit instruction adds actionable guidance for handling failed calls.
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). Use for charting or custom math. Not for live 'what's trending now' boards (use get_top_trends). For most growth questions, use get_growth. If the request is rate limited or the monthly quota is used up, tell the user their plan limit is reached.
| 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. |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the tool read-only and idempotent. The description adds valuable behavioral context: the result includes 0-100 values plus volume when available, and it instructs the agent to inform the user when plan limits are reached. These details go beyond the structured annotations and help the agent set expectations, so a score of 4 is warranted.
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 serving a distinct purpose: core definition, use case, exclusions/alternatives, and error-handling guidance. The most important information is front-loaded and there is no redundancy or fluff. This is a model of concise, action-oriented description writing.
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?
The tool has an output schema, so return shapes need not be repeated. The description covers the core scope, value range, conditional volume field, usage intent, alternatives, and even an edge-case user communication instruction. For a two-parameter tool with rich schemas and sibling context, this description is fully adequate for an agent to select and invoke the tool 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 description coverage is 100% and the parameter descriptions in the schema are extremely detailed, especially for 'source' with per-source validation rules and examples. The tool description adds only a small amount of parameter-related meaning (one keyword and one source per request) beyond what the schema already provides. With full schema coverage, the baseline of 3 applies.
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 and resource: 'Full historical series for one keyword and one source' with the value range (0-100). It clearly distinguishes this tool from siblings by naming what it is not for (live trending boards, growth questions) and naming the alternatives. This leaves no ambiguity about the tool's core function.
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 gives explicit when-to-use guidance ('Use for charting or custom math'), explicit when-not-to-use guidance ('Not for live trending boards'), and names the two sibling tools (get_top_trends, get_growth) as alternatives. It also provides situational handling for rate limiting and quota exhaustion, which is exactly the kind of contextual usage an agent needs.
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', and 'Substack by Category', always pass category. Default sort is current rank. Use sort='rank_change' for climbers vs a prior snapshot (window 1d, 3d, 7d, 14d, or 30d). App Store Top Free, App Store Top Paid, and Google Play are live store boards, not keyword lookups. For an app's history use get_growth or get_time_series with source app downloads or app rankings and an Android bundle ID. Do not use get_time_series for live boards. If the request is rate limited or the monthly quota is used up, tell the user their plan limit is reached.
| 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. | rank |
| 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 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. | 30d |
| category | No | Pass this whenever type is 'Amazon Best Sellers by Category', 'Google Trends by Category', 'Top Websites', or 'Substack by Category'. Use the official name. Without it those feeds mix every board. Only omit on a first pull to learn the official names. |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and openWorldHint, so the safety profile is known. The description adds substantial behavioral context beyond these hints: the board is live, exactly one feed type per call, default sort is current rank, rank_change compares against a prior snapshot with specific windows, and certain store feeds are live boards rather than keyword lookups. The rate-limit/quota handling instruction is also a clear behavioral disclosure. There is 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: core purpose, category requirement, sort/window semantics, differentiation from store keyword lookups, alternative tools, and rate-limit handling. It is front-loaded with the essential purpose and does not contain redundant or filler 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, the rich schema descriptions, the presence of an output schema, and the read-only/idempotent annotations, the description covers all remaining decision points an agent needs. It explains which feed types require category, how sorting and windows work, how to distinguish this tool from siblings, and how to respond to rate limiting or quota exhaustion. Nothing critical is missing for correct selection and 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?
The input schema already documents every parameter with 100% coverage, so the baseline is 3. The description adds meaningful cross-parameter semantics that the schema does not fully convey: which specific feed types require 'category', that 'sort' defaults to current rank and 'rank_change' enables climber comparisons using a 'window', and that the tool is exclusively for live boards rather than keyword or history data. This raises the value above baseline, but because the schema already carries strong per-parameter descriptions, it does not reach 5.
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, concrete definition: 'Live top-trending board for exactly one feed type. No keyword.' This immediately conveys the resource and its core behavior, and it distinguishes the tool from keyword-based or history-based lookups. It also names the sibling alternatives (get_growth, get_time_series) and explains when they are the correct choice, making the scope unmistakable.
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 gives explicit when-to-use and when-not-to-use guidance. It states which feed types require the category parameter, that sort='rank_change' is for climbers with a prior snapshot, and that App Store/Google Play boards are live and not keyword searches. It directly addresses alternatives: 'For an app's history use get_growth or get_time_series... Do not use get_time_series for live boards.' It even instructs how to handle rate limits and quota exhaustion.
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. Dates show when Glama detected each change.
v0.1.0get_growthget_time_seriesget_top_trendsEach tool has a distinct purpose: get_growth for point-to-point changes, get_time_series for full historical series, and get_top_trends for live boards. The descriptions actively cross-reference each other to prevent confusion.
All three tools follow the same get_ prefix followed by a clear noun: get_growth, get_time_series, get_top_trends. The naming pattern is uniform and predictable.
Three tools is a well-scoped size for this server's purpose. Each tool covers a distinct core query type with no redundancy.
The tool set covers growth, historical data, and live trends well. Minor gaps exist around multi-keyword time-series comparison and source/feed discovery, but agents can work around them.
The only News based AI MCP your agents will ever need — custom categories, global regions, and time-scoped results in one tool. We use multi-vector & sparse-hybrid search to search through thousands of articles across the world to find the exact news you're looking for.
News article mention volume trends for any topic. Free key at trendsapi.ai
Real-time corroborated news events + 5-year archive, for agents. Free tier, no key.
News sentiment scores over time, with growth for any topic. Free key at trendsmcp.ai
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/trendsmcp-ai/news-volume-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server