Skip to main content
Glama
HasData

hasdata-mcp

Official

google_trends_search: GET /

hasdata_google_trends_search_getTrendsData

Fetch Google Trends data including interest over time, geographic breakdowns, and related topics/queries. Supports multiple queries, custom dates, and categories for demand forecasting and seasonality analysis.

Instructions

Get Google Trends Data

Pulls Google Trends data for one or more queries with geo targeting, region granularity (country/subregion/metro/city), date range, category, time zone, Google property (web, images, news, shopping, YouTube), and dataType (timeseries, geoMap, relatedTopics, relatedQueries). Returns interest-over-time series, geo-level breakdowns, and rising/top related topics/queries with relative scores. Use for keyword/content strategy, demand forecasting, seasonality analysis, topic discovery, campaign timing, and adding live-trend signals to marketing or research agents.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
qYesSpecify the search term for which you want to retrieve trends data.
geoNoSpecifies the location for the search. Defaults to Worldwide if not set or empty.
regionNoUsed to get more specific results when using "Interest by region" data type. Other data types do not accept this parameter. The default value depends on the geo location that is set. Available options: - `country`: Country - `region`: Subregion - `dma`: Metro - `city`: City Note: Not all region options will return results for every geo location.
dataTypeNoDefines the type of search to perform. Available options: - `timeseries`: Interest over time (default). Accepts both single and multiple queries per search. - `geoMap`: Interest by region. Accepts both single and multiple queries per search. - `relatedTopics`: Related topics. Accepts only single query per search. - `relatedQueries`: Related queries. Accepts only single query per search.
tzNoDefines a time zone offset in minutes. The default value is 420 (Pacific Daylight Time (PDT): UTC-7). The valid range for this parameter is from -1439 to 1439. To calculate the `tz` value for a specific time zone, you can use the time difference between UTC +0 and the desired time zone. Examples: - `420`: Pacific Daylight Time (PDT) - `60`: Central European Time (CET) - `-540`: Japan Standard Time
catNoCategory of the search term. The default value is 0 ("All categories").
gpropNoSorts results by a specific property. The default property is Web Search (applied when the gprop parameter is not set or empty). Available options: - `images`: Image Search - `news`: News Search - `froogle`: Google Shopping - `youtube`: YouTube Search
dateNoDefines a date range for the search. Available options: - `now 1-H`: Past hour - `now 4-H`: Past 4 hours - `now 1-d`: Past day - `now 7-d`: Past 7 days - `today 1-m`: Past 30 days - `today 3-m`: Past 90 days - `today 12-m`: Past 12 months - `today 5-y`: Past 5 years - `all`: 2004 - present You can also specify a custom date range using one of the following formats: - `yyyy-mm-dd yyyy-mm-dd` - (e.g. 2021-10-15 2022-05-25) for dates from 2004 to present. - `yyyy-mm-ddThh yyyy-mm-ddThh` - (e.g. 2022-05-19T10 2022-05-24T22) for dates with hours within a week range. The hours will be calculated based on the tz (time zone) parameter.
Behavior3/5

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

No annotations are provided, so the description carries the full burden. It mentions what is returned (interest-over-time, geo breakdowns, related queries) but lacks details on authentication, rate limits, or data freshness. Adequate but not fully transparent.

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

Conciseness4/5

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

The description is a single paragraph, efficiently covering purpose, parameters, and use cases. It is not overly long but could be slightly more structured. Front-loaded with purpose.

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?

Given the tool's complexity (8 params, no output schema), the description explains output types and use cases well. It lacks details on restrictions or error handling, but covers the essential context for an agent to use it correctly.

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 coverage is 100%, so baseline is 3. The description adds minor context (e.g., multiple vs single query per dataType) but does not significantly enhance understanding beyond the schema's own descriptions.

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 description starts with 'Get Google Trends Data' and elaborates with specific parameters and output types. It clearly distinguishes itself from sibling tools like SERP and Images, as no other tool serves Google Trends data.

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

Usage Guidelines4/5

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

The description lists use cases (keyword strategy, demand forecasting, etc.) but does not explicitly state when not to use or alternatives. However, the name and context make it clear this is the sole Google Trends tool.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/HasData/hasdata-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server