Provides tools to fetch Google Trends data, including keyword interest over time, related queries, and regional popularity.
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., "@Google Trends MCP show me interest over time for 'vegan recipes' in the past year"
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.
The Google Trends MCP server that actually works under Google's anti-bot. Connect Claude to live Google Trends data — keyword interest, related queries, regional popularity.
Most Google Trends MCP packages crash with Unexpected token 'l' the moment Google blocks them (which is often). Free public proxy lists don't help — we tested 64 proxies from a popular "high-quality" list and 0 worked. This one uses your own rotating proxy with auto-retry, so blocked requests transparently retry on a fresh IP.
Built by Denys Malieiev.
What's fixed | Detail |
Free public proxies don't work | We tested 64 — 0 survived. Bring your own rotating residential (Webshare/IPRoyal/Smartproxy free tier = ~46k requests on 1 GB) |
Auto-retry on Google blocks | When Google returns HTML, we retry up to 3 times with a fresh proxy from the pool. End-to-end success rate in our tests: 5/5 |
HTML-detection at the wrapper level | Other MCPs let |
Honest about what doesn't work |
|
Pool with fail-tracking | Proxies that fail 3 times get dropped automatically. Random rotation per request |
Per-request rotation | Each request picks a random proxy from the pool — Google can't accumulate per-IP rate limits |
Related MCP server: Google Trends MCP Server
npx @den.dance/google-trends-mcpWorks out-of-the-box from non-flagged IPs, but Google rate-limits datacenter ranges aggressively. For reliable use, set up a proxy (see below).
Recommended (all have free tiers / pay-per-GB):
Webshare — free 1 GB residential (~46k Google Trends requests)
IPRoyal — $1.75/GB, lowest price
Smartproxy / Decodo — $4-7/GB, large pool
Bright Data / Oxylabs — $5-8/GB, enterprise grade
Make sure the provider allows *.google.com in their ToS (most majors do).
Edit your Claude Desktop config file:
macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Windows: %APPDATA%\Claude\claude_desktop_config.json
Linux: ~/.config/Claude/claude_desktop_config.json
Single rotating endpoint (recommended — provider rotates IPs internally):
{
"mcpServers": {
"google-trends": {
"command": "npx",
"args": ["@den.dance/google-trends-mcp"],
"env": {
"PROXY_URL": "http://USER:PASS@gate.smartproxy.com:7000"
}
}
}
}Or an explicit list (useful for Webshare-style per-port proxies):
{
"mcpServers": {
"google-trends": {
"command": "npx",
"args": ["@den.dance/google-trends-mcp"],
"env": {
"PROXY_LIST": "http://user:pass@host1:6114,http://user:pass@host2:6014,http://user:pass@host3:5863"
}
}
}
}For longer lists, put proxies in a file (one per line, # comments allowed) and point to it:
{
"mcpServers": {
"google-trends": {
"command": "npx",
"args": ["@den.dance/google-trends-mcp"],
"env": {
"PROXY_LIST_FILE": "/home/you/.config/google-trends/proxies.txt"
}
}
}
}# ~/.config/google-trends/proxies.txt
http://user:pass@host1:6114
http://user:pass@host2:6014
http://user:pass@host3:5863chmod 600 the file — credentials live there. Run proxy_refresh from Claude to hot-reload after editing.
Restart Claude Desktop after saving the JSON config.
claude mcp add google-trends \
-e PROXY_URL="http://USER:PASS@gate.smartproxy.com:7000" \
-- npx @den.dance/google-trends-mcpVariable | Required | Description |
| recommended | Single rotating proxy endpoint. Provider handles IP rotation internally. No validation, no fallback |
| alternative | Comma-separated list of proxies ( |
| alternative | Path to a file with one proxy per line ( |
| no | Set to |
Priority: PROXY_URL > PROXY_LIST > PROXY_LIST_FILE. If none are set, requests go direct (no proxy) — works only from non-flagged IPs.
compare_keywords — search interest over time for up to 5 keywords. Returns a timeline of relative scores.
get_related_queries — top + rising related queries for a keyword. Powered by Google's relatedQueries endpoint.
get_interest_by_region — top 20 regions by interest in a keyword.
proxy_status — show source (single / env-list / env-file / none / disabled), working count, age, freshness, validation progress.
proxy_refresh — force re-validation of the current proxy source. No-op in PROXY_URL mode.
get_trending_searches (daily / real-time trends) — Google blocks these endpoints aggressively. Even with residential proxies the success rate is too low to ship. We'd rather not lie about it.
Google sometimes blocks multi-keyword requests (2 or 4 keywords) more aggressively than single. Our auto-retry handles this — but if all 3 attempts hit blocks, the request fails. Increase MAX_ATTEMPTS in trends-client.js if you need higher tolerance.
The underlying google-trends-api library scrapes Google's internal endpoints, which are undocumented and can change. If the library breaks, this MCP breaks too.
For very heavy use (>10k req/day) consider a managed service like SerpAPI or DataForSEO — at that scale the price difference vs your own proxy is marginal and the operational burden disappears.
"Compare search interest for 'claude ai', 'chatgpt', and 'gemini' over the last 12 months"
"What are people searching for related to 'sourdough bread'?"
"Which regions have highest interest in 'electric vehicle'?"
"Show me the proxy pool status"
~450 lines total across server.js (MCP handlers), proxy-manager.js (pool/cache), trends-client.js (retry logic with DI)
Validation: parallel workers (concurrency 50) check each proxy against trends.google.com/api/autocomplete/test, looking for the anti-XSSI prefix )]}' in the response
Cache: working proxies persisted to proxies.json (gitignored), keyed by SHA1 of input list — automatically invalidated when source changes
TTL: 4 hours; background re-validation when cache is stale
Fail tracking: proxies drop from rotation after 3 failures per session
Retry: every tool call retries up to 3 times with fresh getAgent() on HTML response or exception
# Unit only (fast, offline, no network)
npm test
# With coverage report (html in coverage/)
npm run test:coverage
# Integration (real Google hit, gated)
RUN_INTEGRATION=1 npm run test:integration
# E2E (spawns server.js, JSON-RPC over stdio)
RUN_E2E=1 npm run test:e2e
# Everything
npm run test:allserver.js — MCP server entrypoint (stdio transport)
trends-client.js — Google Trends API wrapper with retry-on-HTML
proxy-manager.js — proxy pool, validation, cache, source priority
tests/unit/ — pure unit tests, no network (~40 tests, runs in ~2s)
tests/integration/ — real Google endpoint tests (gated by RUN_INTEGRATION=1)
tests/e2e/ — full MCP protocol tests via spawn (gated by RUN_E2E=1)
Never commit proxy credentials to version control. Use PROXY_LIST_FILE pointing to a chmod 600 file outside the repo, or your secrets manager
proxies.json cache (built from validated proxies) is gitignored and never published — re-generated on first run after install
MIT
Compare search interest over time for up to 5 keywords
| Name | Required | Description | Default |
|---|---|---|---|
| geo | No | Country code e.g. US, RU (default: worldwide) | |
| keywords | Yes | Up to 5 keywords | |
| timeframe | No | e.g. today 12-m, today 5-y | today 12-m |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully bears the burden of disclosing behavioral traits. It only states the basic function, omitting any side effects, read-only nature, authentication needs, or output format. This is insufficient for safe invocation.
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 a single, direct sentence with no wasted words. It is front-loaded with the core action. However, it could be slightly longer to include critical behavioral context without losing conciseness.
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 lack of output schema and annotations, the description is too minimal. It does not explain what the output represents (e.g., a chart or time series), any limitations (e.g., rate limits), or how the tool interacts with other systems. This leaves the agent with incomplete information.
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%, so the description does not need to add parameter details. However, it adds no new meaning beyond what the input schema already provides (e.g., the 'keywords' constraint is already in the schema). Baseline score 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 uses a specific verb ('compare') and resource ('search interest over time') with a clear constraint ('up to 5 keywords'). It distinguishes itself from sibling tools like 'get_related_queries' and 'get_interest_by_region' which handle different aspects of search data.
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 implies usage for comparing keyword trends over time, but does not explicitly state when to use it versus alternatives or provide any exclusion criteria. It gives no guidance on when not to use it or which sibling tools to prefer.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get search interest by region/country for a keyword
| Name | Required | Description | Default |
|---|---|---|---|
| geo | No | ||
| keyword | Yes | ||
| timeframe | No | today 12-m |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description must carry the burden of behavioral disclosure. It does not mention any behavioral traits such as data freshness, rate limits, authentication, or what happens with default parameters.
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 too short, lacking necessary details about parameters and behavior. It is under-specified rather than genuinely concise, sacrificing completeness for brevity.
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 3 parameters, no output schema, and no annotations, the description is severely incomplete. It omits parameter explanations, return format, and usage notes, leaving the agent under-informed.
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 0%, yet the description provides no explanation of the parameters (geo, timeframe) beyond what is in the schema. The agent receives no additional semantic meaning for correct usage.
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 verb 'Get', the resource 'search interest', and the qualifiers 'by region/country' and 'for a keyword', making the purpose specific and distinguishable from sibling tools like compare_keywords.
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?
No guidance on when to use this tool versus alternatives (e.g., compare_keywords, get_related_queries). The description lacks context about appropriate use cases or constraints.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Re-validate the current proxy source (PROXY_LIST or PROXY_LIST_FILE). Blocks until done. No-op for PROXY_URL single-proxy mode.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description discloses blocking behavior and no-op condition, which are essential behavioral traits. It does not detail error handling or side effects, but for a zero-parameter tool, this is sufficient.
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 two sentences, each carrying essential information: purpose first, then behavioral notes. No wasted words, highly efficient.
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 zero-parameter tool with no output schema, the description covers purpose, behavior (blocks), and edge case (no-op). No gaps remain; it is fully complete.
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?
There are no parameters, so the description need not add parameter info. The schema has 100% coverage, and the description's lack of parameter details is appropriate for a zero-parameter tool, earning a baseline of 4.
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 verb 'Re-validate' and the resource 'current proxy source', distinguishing between list and single-proxy modes. It differentiates from sibling 'proxy_status' by focusing on the action of refreshing rather than checking status.
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 provides key usage context: blocking behavior and no-op for single-proxy mode. It implies when not to use (single-proxy), but does not explicitly mention alternatives or when to prefer this over sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Show proxy pool status: source, working count, age, freshness, and validation progress
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It lists output fields but does not disclose whether the tool is read-only, has side effects, or other behavioral traits. While 'show' implies read-only, it is not explicit.
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 a single sentence with 11 words, front-loading the purpose ('Show proxy pool status') and efficiently listing the key fields. Every word earns its place.
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 has no parameters and no output schema, the description adequately covers the functionality by listing the output fields. It could mention that the tool is read-only or returns a JSON object, but it is sufficient for a simple status 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?
There are no parameters, so the baseline is 4. The description adds no parameter information, but none is needed since the input schema already covers the zero parameters completely.
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 uses a specific verb ('Show') and clearly identifies the resource ('proxy pool status'). It lists the returned fields (source, working count, age, freshness, validation progress), which distinguishes it from sibling tools like proxy_refresh that perform an action.
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 implies use when you need to check proxy pool status, but provides no explicit guidance on when to prefer this tool over alternatives like proxy_refresh. No exclusions or context for usage are given.
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.
v1.0.0compare_keywordsget_interest_by_regionget_related_queriesproxy_refreshproxy_statusEach tool has a clearly distinct purpose: proxy_status and proxy_refresh handle proxy pool management, while compare_keywords, get_related_queries, and get_interest_by_region each perform a different Google Trends data retrieval operation. There is no overlap.
All tool names follow a consistent verb_noun pattern in snake_case (proxy_status, proxy_refresh, compare_keywords, get_related_queries, get_interest_by_region), making them predictable.
With 5 tools, the server is compact but reasonable. The proxy tools are necessary for maintenance, and the three trends tools cover common queries, though more could be added for a full-featured Trends API.
The trends surface lacks a basic single-keyword interest-over-time tool and missing features like time range or category filtering. Proxy tools are complete for their purpose, but the overall domain coverage has notable gaps.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Google Trends: Search, Images, News, Shopping over time, growth metrics. Free key at trendsmcp.ai
Trend data from Google Trends, YouTube, TikTok, Reddit, Amazon, Wikipedia, npm, Steam and more
Trend data from Google, TikTok, Amazon, Reddit, YouTube, Steam, npm and more as JSON
Web search, scraping, Google Trends and data lookups. Paid per call in USDC on Base via x402.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/den-indance/google-trends-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server