google-trends-mcp-server

Google Trends: trending searches

get_trending_searches

Read-only

Retrieve trending Google searches by country and time window, including search volume and related queries, to support news monitoring, content ideas, and market research.

Instructions

Get what people are searching for right now on Google in a country: the trending searches of the last 4, 24, 48 or 168 hours, with search volume and related queries. Use it for news, content ideas or market monitoring.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "get_trending_searches"
  }
}

Input Schema

Name	Required	Description	Default
`hours`	No	Look-back window in hours	24
`country`	No	Country code, e.g. US, GB, FR, DE, IN, BR, JP (125 countries)	US
`max_results`	No	Number of trending searches to return

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Nov 15, 2026

TDQS

A3.7/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the description's job is to add context beyond that, which it does by disclosing data freshness ("right now"), the supported look-back windows, and the shape of the payload (search volume and related queries). It stops short of mentioning rate limits, quotas, or country-coverage caveats, but the added behavioral value is real.

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?

Two front-loaded sentences with essentially no filler: the payload and scope come first, the use cases second. There is a slight tension between "right now" and a 168-hour window, but it does not cost much clarity.

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?

All three parameters are optional with sensible defaults, so an agent can call it with no arguments, and the description states what comes back even though no output schema exists. Combined with the annotations covering the safety profile, this is nearly complete; only the sibling-relationship detail is missing.

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% and all three parameters are documented in the schema with defaults and an enum. The description restates the hours windows and the country scoping but adds no format or interaction detail beyond that, so the baseline of 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb and resource ("Get what people are searching for right now on Google in a country") and names the concrete data returned (trending searches, search volume, related queries). It is clear what the tool produces, though it does not explicitly differentiate itself from the sibling get_interest_over_time.

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?

It offers use-case hints ("news, content ideas or market monitoring"), which implies when the tool is appropriate. However, there is no explicit when-not-to-use guidance and no routing to the sibling get_interest_over_time for historical or term-specific interest data, leaving the choice between the two to inference.

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

Deploy Server