trendzeist-mcp

Overview Schema Source Related Servers Discussions Admin

what_changed

Compare current Google Trends data with local snapshots for 1–5 seeds over 1–90 days to spot new breakouts, rising or cooled queries, rank moves, and direction changes for review.

Instructions

What changed for 1-5 seeds since the last snapshot at least since_days (1-90) old: new_breakouts and promoted (action: investigate now), new_rising (consider), cooled / dropped queries (review: verify with interest_over_time before retiring, or refresh existing post), rank_moves and a direction_flip on direction_now. Leaving Google's relative list is not proof of falling demand. Refreshes current data first (1 + N requests, cached), then compares complete snapshots from the local observation archive, which fills up as any tool fetches fresh data. No snapshot old enough -> compares with the oldest available (baseline_note gives its real age); first run -> first_seen lists the current breakouts and rising queries ('no history yet') plus the date to rerun.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "seeds": "<seeds>"
    },
    "name": "what_changed"
  }
}

Input Schema

Name	Required	Description	Default
`geo`	No
`seeds`	Yes
`since_days`	No

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Addedv0.5.0Oct 17, 2026

TDQS

A3.8/5.0

Behavior5/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 so well: it discloses cost ('1 + N requests, cached'), the ordering of work (refresh first, then compare archived snapshots), the dependency that the archive only grows as other tools fetch data, and two edge behaviors — falling back to the oldest available snapshot with 'baseline_note' reporting its real age, and the first-run 'no history yet' response with a rerun date.

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

Conciseness3/5

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

Nearly every sentence earns its place, but the structure is poor: the opening sentence is a run-on fragment mixing scope, bounds, and output categories, and the parenthetical asides interrupt the flow. Front-loading is present in spirit but obscured by the telegraphic phrasing.

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?

An output schema exists, yet the description still names the key returned fields (new_breakouts, promoted, new_rising, cooled/dropped, rank_moves, direction_flip, baseline_note, first_seen) so an agent can reason about results without introspecting. It also warns against a misreading ('leaving Google's relative list is not proof of falling demand'). The one real gap is the undocumented geo parameter.

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 0%, so the description must compensate. It adds genuine meaning for two of three parameters — the 1-5 cap on seeds and the 1-90 range on since_days (plus the 'at least' semantics) — but 'geo' is never mentioned anywhere, leaving one parameter entirely undocumented in both schema and description.

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?

States a specific operation (diff of breakout/rising/rank movement signals) over a specific resource (the seed's trend snapshot history), with bounds on inputs ('1-5 seeds', 'since_days (1-90)'). It is distinguishable from siblings like trending_now or trend_history, though the opening clause is grammatically fragmented and takes a second read to parse.

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?

Gives actionable per-category guidance ('investigate now', 'consider', 'verify with interest_over_time before retiring, or refresh existing post'), which is real when-to-act direction. However, it never says when to choose this tool over trend_history or trending_now for the same question, and prerequisites are only implied ('archive fills up as any tool fetches fresh data').

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