Skip to main content
Glama

Vee3

by io.github.Vee3io

google-trends.interest_over_time

Fetch Google Trends interest-over-time series for one to five keywords.

Returns a JSON object whose top-level keys are your keywords. Each value maps timestamps to interest scores (0–100). Granularity depends on the requested date range (from about one minute to monthly buckets).

Requires start in datetime-with-timezone form (for example 2020-05-01T00:43:37+0100). Optional end defaults to now. country defaults to global; region requires a valid country. category and gprop default to all when omitted or empty.

Cost = 40 tokens.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
endNoRange end in datetime-with-timezone form. Defaults to now.
gpropNoGoogle property filter (for example images, news, youtube, froogle). Defaults to all.
startYesRange start in datetime-with-timezone form (for example 2020-05-01T00:43:37+0100).
regionNoRegion within country. Requires country when set.
countryNoCountry name for geo filtering. Defaults to global.
categoryNoTrends category or subcategory. Defaults to all.
keywordsYesUp to five keywords to compare.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. First observed

TDQS

A3.9/5.0
Behavior4/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It reveals return structure (JSON object keyed by keywords), value semantics (timestamps to 0–100 scores), granularity behavior (depends on date range), and defaults for optional parameters. It does not address errors or rate limits, but for a read-only data fetch tool this is robust.

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 four sentences with each sentence carrying information: purpose, output shape, granularity, parameter constraints, and cost. It is front-loaded and free of fluff, though it slightly redundantly repeats schema notes about start and defaults.

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 presence of an output schema and full parameter descriptions, the description adds the crucial output mapping (keywords to timestamp-score pairs), granularity dependency, and token cost. It covers the tool's essentials well, but could add a note about when to prefer sibling tools for regional or related-query analysis.

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 all seven parameters already have descriptive text. The description repeats some of this (e.g., start format, defaults) and adds output mapping context, but does not introduce new parameter-level semantics beyond what the schema provides. Baseline 3 is appropriate.

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 opens with 'Fetch Google Trends interest-over-time series for one to five keywords,' which is a specific verb+resource statement. It clearly distinguishes this tool from siblings like interest_by_region, related_queries, and suggestions by naming the exact time-series output.

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?

The description implies usage context (time-series analysis over a date range) but does not explicitly state when to use this tool instead of alternatives, nor does it mention any exclusions. It offers parameter prerequisites (e.g., requires start in datetime-with-timezone form) but no direct comparison to sibling tools.

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

All Vee3 toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.1/5.0
Disambiguation5/5

Each tool has a distinct purpose, further clarified by group prefixes and clear descriptions. Within each group, tools perform different operations (e.g., domains.lookup vs. domains.whois vs. domains.rdap) with no ambiguity.

Naming Consistency5/5

All tools follow a consistent group.tool_name pattern using snake_case. The naming is predictable and uniformly applied across all groups.

Tool Count4/5

78 tools is high, but the server aggregates multiple distinct API domains (11 groups). Each group has a reasonable number of tools, typically under 10, with TikTok having 17. The count reflects breadth, not bloat.

Completeness5/5

Each domain's tool set covers the primary expected operations (e.g., search, details, reviews, metrics, user info). There are no obvious gaps for read-only analytical use; features like posting are likely out of scope.

Resources