Provides tools for retrieving Google Trends data for search terms, including interest over time, interest by region, related queries and topics, comparative charts, and summary metrics such as average, latest, and peak interest.
Click on "Deploy 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., "@Google Trends Scraper MCP Server Compare coffee and matcha interest in the US over the last 12 months."
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.
An MCP server for the Mamba Labs Google Trends Scraper actor on Apify. Read Google Trends for your search terms and get a summary row per term plus flat detail rows.
Related MCP server: google-search-trends-mcp
Give search terms, with a geo, timeframe, category, or search property if you want them. For each term you get one summary row (average, latest, and peak interest, recent change, top region, top and rising queries) and flat rows for interest over time, regions, and related queries. Terms can be compared in groups of 5 on one scale. Values are relative to the chart, not search counts.
All of the work runs on Apify. This package is a thin client that starts the actor run, waits for it, and hands back the dataset rows.
You need Node.js 18 or newer and an Apify account with an API token.
Add this to your Claude Desktop config (claude_desktop_config.json), Cursor, or any MCP client:
{
"mcpServers": {
"mamba-google-trends-scraper": {
"command": "npx",
"args": [
"-y",
"@mambalabsdev/mcp-google-trends-scraper"
],
"env": {
"APIFY_TOKEN": "your-apify-token"
}
}
}
}Restart the client. The get_google_trends tool appears.
Node.js 18 or newer.
An Apify API token from console.apify.com/account/integrations, set as APIFY_TOKEN. The server lists its tool without a token; a call needs one.
"How has interest in matcha changed in the US over the last 12 months?"
"Compare coffee and tea by US metro area."
"What are the rising search queries around ozempic?"
get_google_trends. One tool. Example arguments:
{
"terms": [
"coffee",
"matcha"
],
"geo": "US",
"timeframe": "today 12-m"
}Every buyer facing input of the actor. Omitted inputs take the actor's own defaults.
Input | Type | Required | Description |
| array | no | Search terms, up to 200 per run. A Google topic ID such as /m/0j6n6s8 also works. |
| string | no | Empty for worldwide, or a Google geo code such as US, DE, or US-CA. |
| string | no | now 1-H, now 4-H, now 1-d, now 7-d, today 1-m, today 3-m, today 12-m, today 5-y, all, or two dates as YYYY-MM-DD YYYY-MM-DD. |
| string | no | Google Trends category number. 0 is all categories. The number is in the cat= part of a Trends URL. |
| string | no | Which Google search to read: web, news, images, youtube, or shopping. |
| boolean | no | true: terms are charted together in groups of 5, on one shared scale. false: each term gets its own chart. Each term is charged either way. |
| array | no | Any of interest_over_time, interest_by_region, related_queries, related_topics. Default is the first three. See Limitations for related_topics. |
| string | no | auto: countries worldwide, regions inside a country. DMA is US metro areas. CITY needs a geo. COUNTRY needs an empty geo. |
| string | no | Optional. The run stops before a charge that would pass this amount. Summary rows are always returned. |
| string | no | auto (default): requests go through the Apify proxy pool, and a request the pool cannot get through is retried on residential addresses. residential: every request uses residential addresses. A reliability setting only; it does not change what you pay. |
Pay per event on Apify, billed to your Apify account. Prices in USD.
Event | Free plan | Bronze | Silver | Gold |
| $0.0065 | $0.006175 | $0.00585 | $0.005525 |
| $0.0035 | $0.003325 | $0.00315 | $0.002975 |
| $0.002 | $0.002 | $0.002 | $0.002 |
A term with no data, a term Google refused, and refused input are free. Mamba Labs pays the platform costs of the run, Apify proxy traffic included.
apify.com/mambalabs/google-trends-scraper
MIT. See LICENSE.
Read Google Trends for search terms: a summary per term (average, latest, and peak interest, recent change, top region, top and rising queries) plus flat rows for interest over time, by region, metro, or city, and related queries. Values are relative 0 to 100, not search counts. Compare up to 5 terms on one scale. No Google account or key.
| Name | Required | Description | Default |
|---|---|---|---|
| geo | No | Empty for worldwide, or a Google geo code such as US, DE, or US-CA. | |
| terms | No | Search terms, up to 200 per run. A Google topic ID such as /m/0j6n6s8 also works. | |
| compare | No | true: terms are charted together in groups of 5, on one shared scale. false: each term gets its own chart. Each term is charged either way. | |
| outputs | No | Any of interest_over_time, interest_by_region, related_queries, related_topics. Default is the first three. See Limitations for related_topics. | |
| category | No | Google Trends category number. 0 is all categories. The number is in the cat= part of a Trends URL. | |
| property | No | Which Google search to read: web, news, images, youtube, or shopping. | |
| timeframe | No | now 1-H, now 4-H, now 1-d, now 7-d, today 1-m, today 3-m, today 12-m, today 5-y, all, or two dates as YYYY-MM-DD YYYY-MM-DD. | |
| proxy_mode | No | auto (default): requests go through the Apify proxy pool, and a request the pool cannot get through is retried on residential addresses. residential: every request uses residential addresses. A reliability setting only; it does not change what you pay. | |
| max_charge_usd | No | Optional. The run stops before a charge that would pass this amount. Summary rows are always returned. | |
| region_resolution | No | auto: countries worldwide, regions inside a country. DMA is US metro areas. CITY needs a geo. COUNTRY needs an empty geo. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, idempotent, non-destructive, open-world), so the description is not obligated to restate them. It instead adds genuinely useful behavioral context: values are relative 0-100 rather than search counts, no account or key is needed, and comparison is capped at 5 terms. It does not discuss rate limiting, retry behavior, or result-size characteristics, which keeps it below a 5.
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?
Purpose and output contents are front-loaded in the first sentence, with cost/auth/comparison facts trailing in short sentences that each carry distinct information. It is dense and slightly list-heavy, but no sentence is filler; a small trim of the parenthetical enumeration would make it tighter without losing signal.
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?
With no output schema, the description takes on the burden of explaining return values and does so by naming the summary fields and the flat-row categories. It also covers authentication (none), value scale, and comparison limits, which are the facts an agent most needs before calling. Missing are result volume/pagination expectations and any note on latency or failure modes for a 10-parameter scraping tool.
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%, so every parameter already has documentation and the baseline is 3. The description's added meaning ("Compare up to 5 terms on one scale") largely restates the schema's compare parameter, and the 0-100 relative-value note is about output interpretation rather than parameter semantics. Little is contributed beyond the structured fields.
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 ("Read Google Trends for search terms") and immediately enumerates what comes back: a per-term summary with average, latest, peak interest, recent change, top region, and top/rising queries, plus flat rows for interest over time, by region/metro/city, and related queries. An agent knows exactly what this tool produces without opening the schema, and no sibling tools exist to be confused with.
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?
Usage constraints are stated (up to 5 terms on one scale when comparing, no Google account or key required), which tells the agent the practical bounds of a call. However, there is no explicit when-to-use / when-not-to-use framing, nor any guidance on choosing among the many timeframes, output types, or geo modes beyond what the schema already documents. Adequate but clearly implied rather than directed.
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.
v1.0.0get_google_trendsScored across 1 tool
There is only one tool, so there is no possibility of misselection between tools. Its purpose (reading Google Trends data for search terms) is stated explicitly and is distinct from any other exposed operation.
The single tool follows a clear verb_noun snake_case pattern (get_google_trends) that names both the action and the target service. Nothing deviates from this convention.
A one-tool surface is thin: the tool bundles summary, interest-over-time, region/metro/city breakdowns, and related queries into one overloaded call. Users cannot request a single dimension without committing to the whole bundle, and there is no companion tool for related operations (e.g. realtime trends or keyword lookup).
Coverage of the Google Trends domain is solid for a scraper: per-term summary stats, time series, geographic breakdowns at multiple granularities, and related/rising queries. Minor gaps remain, such as no realtime/trending-searches feed and no way to persist or export results.
Bulk Google Trends: interest over time, regions, rising queries and plain-English trend summaries.
Google Trends for any number of keywords on one scale: interest over time, regions, rising queries.
Google Trends data as JSON: interest over time, rising and top queries, regions, Trending Now.
Google Trends interest over time, by region, related queries and Trending now, as JSON.