Skip to main content
Glama
Pangolin-spg

Pangolinfo Amazon Data MCP

by Pangolin-spg
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

keyword_trends

Analyze keyword popularity trends via Google Trends: compare up to five terms by region and time, identify seasonality, and find rising breakout queries for product research.

Instructions

[Keyword Trends via Google Trends] Keyword popularity (data source: Google Trends; use must comply with Google Terms of Service). Time series + per-region heatmap + rising related queries (with 'Breakout' tags). Compare up to 5 keywords on one chart. Use when: user says "how hot is keyword X" / "A vs B popularity" / "any seasonality" / "which states love X" / "find breakout terms" / "new-product direction" / "trend comparison" / "is X past its peak yet". Don't use: for absolute search volume (Trends is 0-100 relative); for products/links (use search_amazon / ai_search); for a single keyword's snapshot (need ≥ 2 for meaningful comparison). Returns: data.json.{ keywordsGeoData[{ keyword, geoMapData[{ geoCode, geoName, value[], formattedValue[], hasData[] }] }], keywordsRankData[{ keyword, rankList[{ rankedKeyword[{ query, value, formattedValue, link, hasData }] }] }], timelineData[{ time, formattedTime, value[], formattedValue[] }], geoMapData[] }, taskId, url. Pair with: ↑ keywords from user or core terms found via search_amazon; ↓ feed Breakout/rising terms back into search_amazon to explore new opportunities, or filter_niches to see if they've crystallized into a niche. Cost: ~1.5 points/call, ~5s. Tips: timeRange = today 12-m (default) | today 3-m | today 5-y | all ; region = ISO country code or 'WORLD'; language affects related-query language.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
regionNoRegion code (ISO country, or 'WORLD' for global). Common: 'US' / 'GB' / 'DE' / 'JP' / 'CN'.US
keywordsYesKeywords to compare (1-5). Examples: ['wireless earbuds', 'bluetooth earbuds'] (synonyms) / ['stanley quencher', 'yeti rambler', 'hydro flask'] (competing brands) / ['halloween costume'] (single keyword for seasonality).
languageNoInterface language (BCP-47), affects related-query language. Defaults to 'en-US'. Use 'zh-CN' for Chinese.en-US
timeRangeNoTime window. Common: 'today 12-m' (last 12 months, default), 'today 3-m' (last 90 days), 'today 5-y' (5-year long-term), 'all' (since 2004).today 12-m
clientSourceNo调用来源标记。仅由 Pangolinfo Skill 传 skill；普通 MCP 调用省略即可。

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.2

TDQS

A4.6/5.0
Behavior4/5

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

With no annotations, the description carries the full behavioral burden and does so substantially: it discloses the cost (~1.5 points/call), latency (~5s), the Google Trends data source, a ToS compliance obligation, and the critical 0-100 relative-scale caveat. It omits auth/permission requirements and rate limits, keeping it short of a 5, but the disclosure is well above average for an unannotated tool.

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?

Strongly front-loaded with purpose, then cleanly sectioned into Use when / Don't use / Returns / Pair with / Cost / Tips. It is longer than typical, and the raw inline dump of the nested return JSON is dense, but each section contributes concrete value rather than filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Absent both annotations and an output schema, the description fully compensates: it enumerates the return structure in detail, states cost and latency, and documents every meaningful parameter behavior. Nothing essential for correct invocation or result interpretation is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is already 100%, so baseline is 3, but the description adds practical semantics beyond the schema: recommended timeRange values, 'WORLD' vs ISO country for region, and the note that language drives related-query language. The Tips section reinforces parameter usage in a way the schema fields alone do not.

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?

States a specific tool function (keyword popularity trends from Google Trends) and its outputs (time series, per-region heatmap, rising related queries) up front. It clearly distinguishes itself from siblings by naming search_amazon and ai_search as the tools for other tasks. An agent can identify this tool's domain without opening the schema.

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

Usage Guidelines5/5

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

Contains an explicit 'Use when' list of user phrasings and a 'Don't use' list that names concrete alternative tools (search_amazon, ai_search) and the conditions that select them (absolute volume, products/links, single-keyword snapshots). The routing logic is fully spelled out rather than implied.

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

Deploy Server

Other Tools