Loading ToolBench
MCP server for Google Trends — trending searches, topic lookup, interest over time, by region, and related queries.
Strong tool definitions with excellent descriptions and clear naming. All 6 tools follow verb_noun convention (search_topics, get_interest_over_time, etc.). Descriptions are LLM-optimized (100-250 chars), explicitly state WHEN to use each tool, and include critical caveats (e.g., 'Values are normalized relative interest, not absolute search volume'). Input schemas are complete with proper types, enums, and descriptions. However, output schemas are not documented in the visible code, only input schemas are shown. Error handling returns structured fail() responses but lacks recovery guidance. No tool annotations (readOnlyHint, destructiveHint) despite all tools being READ_ONLY.
Break down search interest for one term by geography. Use this when the user asks where something is popular, or wants a regional or city-level comparison. Values are Google's normalized relative interest (0-100 within the result set), not absolute search volume.
Get relative search interest for one or more terms over a historical period. Use this when the user asks how popular something is, whether it is rising or falling, or how several things compare — passing multiple keywords compares them against each other on one scale. Values are Google's normalized relative interest (0-100 within the result set), not absolute search volume.
Find the top and rising searches related to a term. Use this for keyword discovery, SEO and content research, finding what people search alongside a topic, and spotting breakout queries. `top` is ranked by volume; `rising` is ranked by growth, where a "Breakout" value means growth too large to measure.
List searches surging right now in a country. Use this for discovery — what is spiking without the user naming a term — and for news, monitoring, and real-time questions. Choose backend "rss" when the user wants to know *why* something is trending: it returns the news articles behind each entry, which the default source does not carry.
Output schemas not documented. Tool descriptions explain what is returned (e.g., 'interest over time', 'regional breakdown') but the actual response structure is not visible in the provided code. LLMs cannot plan downstream operations without knowing field names and types.
No tool annotations despite all tools being READ_ONLY. Adding readOnlyHint=true to all 6 tools would signal to agents that these calls are safe to retry and have no side effects.
Error handling returns fail(error) with no recovery guidance. When a tool fails (e.g., rate limit, invalid region), the LLM receives only the error but no hint about what to try next or whether to retry.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 66 | 2026-07-28+ | v2 |
Full picture of one term in a single call: interest over time, where it is popular, and what people search alongside it. Use this when the user asks to "research", "analyse", or "look into" a topic rather than asking one narrow question — it saves three round trips. Each section is fetched independently, so a partial result is normal: any section that fails carries an `error` instead of data, and the rest still returns. Pass a topic id from search_topics for materially better numbers.
Look up the Google Trends topic id for a thing. Call this FIRST whenever the user names an entity — a company, product, person, technology, concept — then pass the returned `mid` as a keyword to the other tools. A topic aggregates every spelling and translation of the same concept, so it measures far more search activity than the literal phrase: querying the topic for "artificial intelligence" scores 62 where the literal string scores 1. The `type` field disambiguates same-name entities (Nike the company vs the goddess). Skip this only when the user explicitly wants a literal phrase. Cheapest tool here: it needs no cookie and works on IPs that rate-limit the others.
research_trend tool description states 'Each section is fetched independently, so a partial result is normal' but the input schema and error handling do not reflect how partial failures are represented in the response. LLMs cannot distinguish between a complete failure and a partial one.
get_trending_now backend parameter enum includes 'auto' but the description does not clearly explain the fallback behavior or when 'auto' is preferred over explicit 'rpc' or 'rss'.