subimpact-data-mcp

Official

Overview Schema Source Related Servers Discussions Admin

google_trends

Scrape search-interest timelines, related queries/topics, and per-region interest for keywords from Google Trends without API keys, browsers, or captchas.

Instructions

Google Trends Scraper (Keyless)

Scrape Google Trends interest-over-time, related queries/topics, and per-region interest for keywords. No API key, no browser, no captcha. Up to 5 keywords compared per call. From $2.50 per 1,000 keywords (less on paid plans), charged only for delivered keywords.

Pricing (pay per event, billed to your Apify account): Keyword trends bundle: $0.0025; platform usage billed to your account.

Runs on Apify as subimpact/google-trends-scraper-keyless.

Input Schema

Name	Required	Description	Default
`geo`	No	Two-letter country code (US, MY, GB...). Leave empty for worldwide.	US
`category`	No	Google Trends category id (0 = all categories).
`keywords`	Yes	Keywords to track. Up to 5 are compared in one Trends call; more are split into batches. Max 100.
`property`	No	Web search (''), images, news, youtube, or froogle (Google Shopping).
`tzOffset`	No	e.g. -480 for UTC+8. Affects hourly/daily bucketing.
`_maxItems`	No	How many dataset items to return to the model (1-1000, default 50). Truncates the response only; it does not change what the Actor collects or charges for.
`batchSize`	No	Max keywords compared per Trends call (Google allows up to 5).
`timeRange`	No	Trends time range. For a custom range, run via API with 'YYYY-MM-DD YYYY-MM-DD'.	today 12-m
`delaySeconds`	No	Politeness delay. Raise if you see 429 warnings.
`_maxChargeUsd`	No	Per-run spending cap in USD (default 0.5). Passed to Apify as the run option maxTotalChargeUsd, so the run stops when it reaches this charge.
`includeGeoMap`	No	Emit per-region interest rows (states/provinces of the target geo).
`maxRelatedItems`	No	Cap per TOP/RISING list (Google returns ~25).
`includeTimeseries`	No	Emit timeline rows (0-100 interest per period).
`proxyConfiguration`	No	Optional. Add RESIDENTIAL proxy if datacenter IPs get throttled (HTTP 429).
`includeRelatedTopics`	No	Emit related topics (may be empty on some egress IPs).
`includeRelatedQueries`	No	Emit TOP + RISING related queries per keyword.

Schema Changelog

Changes observed during successful MCP inspections.

First observedv1.0.0Oct 24, 2026

TDQS

A4/5.0

Behavior4/5

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

With no annotations, the description carries the full burden and does disclose cost behavior ('$2.50 per 1,000 keywords, charged only for delivered keywords', platform usage billed to the Apify account) plus the access profile (keyless, no browser, no captcha) and the batching constraint. It stops short of describing the actual dataset item shape or failure modes, which matters since no output schema exists.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Capability statement is front-loaded, followed by access/cost qualifiers and the actor identifier. Every line carries distinct information (what it scrapes, cost, batching, runtime) with no filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 16-parameter tool with no annotations and no output schema, the description covers cost, batching, keyless access, and the three output modes well, and the per-parameter schema is fully documented. What is missing is a description of the returned dataset items/fields, which the agent must infer from the include* booleans.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the baseline is 3. The description reinforces the '5 keywords per call' comparison limit for the keywords param and the per-keyword billing model, but adds no syntax, format, or interaction detail the schema does not already give.

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 opening line names a specific verb and resource ('Scrape Google Trends interest-over-time, related queries/topics, and per-region interest for keywords') and enumerates the three output modes. No sibling tool (google_search, google_ads_transparency, youtube) overlaps this scope, so an agent can select it unambiguously.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is implied rather than stated: 'No API key, no browser, no captcha' and the per-keyword pricing tell the agent this is the cheap keyless route for Trends data, but there is no explicit when-to-use/when-not or named alternative. The batching note ('Up to 5 keywords compared per call') is the closest thing to operational guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

google_trends

Instructions

Input Schema

Schema Changelog

TDQS

Other Tools