Amazon India Product Research MCP

analyze_evergreen

Evaluate whether a product has stable year-round demand or is seasonal/fad using up to 5 years of search interest. Receive an evergreen score, stability metrics, and inventory guidance.

Instructions

Decide whether a product has evergreen (year-round) demand or is seasonal / a fad, using up to 5 years of search interest. Returns an evergreen score 0-100, a verdict (Evergreen to Highly Seasonal), stability / flatness / demand-floor / growth components, and inventory guidance. Uses live Google Trends when enabled - free, no API key.

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": {
      "product_name": "<product_name>"
    },
    "name": "analyze_evergreen"
  }
}

Input Schema

Name	Required	Default
`geo`	No	IN
`years`	No	5y
`product_name`	Yes

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.2.1Aug 23, 2026

TDQS

A3.8/5.0

Behavior4/5

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

Since no annotations are provided, the description carries the full burden, and it mostly delivers: it discloses the data source (live Google Trends), the timeframe (up to 5 years), the dependence ('when enabled'), and enumerates the full output contract (score, verdict, four components, inventory guidance). The 'when enabled' caveat also honestly flags the fallback behavior. It loses a point for not disclosing failure modes (e.g., what happens when Google Trends is unavailable).

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 sentences carry a dense payload with no fluff. The core purpose and scope are front-loaded, followed by the return contract and tooling note. The 'stability / flatness / demand-floor / growth components' is mildly listy but efficient. Only minor trimming could be done; overall it respects the reader's attention.

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 there is an output schema, the description is right not to belabor return values. It covers the key behavioral aspects: the decision being made, the data source, the lookback window, and cost/API implications. Missing elements like rate limits or guidance on which product names are valid, but the presence of an output schema plus the behavioral disclosure makes this largely adequate for correct invocation.

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

Parameters2/5

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

With 0% schema description coverage, the description must compensate, but it only implicitly documents the 'years' parameter via the phrase 'up to 5 years of search interest', which matches the default '5y'. The 'geo' parameter (defaulting to IN) and 'product_name' are never explained semantically, and no guidance is given on expected formats or constraints. The description gives partial credit to years but leaves the other two parameters to the agent's guesswork.

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 leads with a specific verb ('Decide whether'), the resource (product demand type), and the distinguishing scope (5 years of search interest). It clearly differentiates this from the large sibling set by naming the exact output (evergreen vs. seasonal verdict), which is what sets it apart from other demand/buying analysts like analyze_product_demand or find_product_opportunities.

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 by explaining the data source and the 'when enabled' dependency on Google Trends, and it signals that it's a free, key-less operation. However, it never explicitly states when to choose this tool over the 23 siblings (e.g., analyze_product_demand or find_product_opportunities), leaving the routing decision to the agent's inference. No exclusions or comparison conditions are given.

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