Pass preset windows to get_growth, read which aliases share dates, and see why monthly sources fail 7D while app downloads still print a week.
Live data as of 2026-09-02
get_growth on Trends MCP returns point-to-point percent change for one keyword on one source, or on a comma-separated list. Omit percent_growth and the window is 12M. On the 2026-09-02 pull, nike on google search with no window list returned index 66.0 on 2026-08-29 versus 68.0 on 2025-08-30, growth -2.94%, across 261 weekly points. 1W matched 7D. 1Y matched 12M. Monthly Amazon, Steam, and Wikipedia series returned collapsed_range on 7D. app downloads printed a real 7D row. Extra presets in one body still count as one source-keyword request. Custom {recent, baseline} objects are REST-only; MCP takes the string windows.
From the Trends MCP pull of 2026-09-02, a nike google search call with thirteen presets completed 13 calculations on 261 weekly points, and a second call that omitted percent_growth returned only the 12M row, the same -2.94% print.
Alias pairs that shared dates and growth on that nike series:
| Labels | Baseline date | Baseline index | Growth |
|---|---|---|---|
| 7D and 1W | 2026-08-22 | 65.0 | +1.54% |
| 14D and 2W | 2026-08-15 | 65.0 | +1.54% |
| 30D, 1M, and MTD | 2026-08-01 | 66.0 | 0.0% |
| 12M and 1Y | 2025-08-30 | 68.0 | -2.94% |
| 24M and 2Y | 2024-08-31 | 66.0 | 0.0% |
| 36M and 3Y | 2023-08-26 | 69.0 | -4.35% |
| 48M and 4Y | 2022-08-27 | 76.0 | -13.16% |
| 60M and 5Y | 2021-09-04 | 71.0 | -7.04% |
Recent index was 66.0 on 2026-08-29 for every row. volume_estimated was true, recent_volume printed 27,100,000, and volume_growth was omitted because that volume is derived from the index. Quote the 0-100 value. google shopping on air fryer also matched 7D to 1W and 14D to 2W (8.0 versus 6.0, +33.33%) on 260 points, with recent_date in datetime form 2026-08-22 00:00:00+00:00 and no volume fields.
Windows that did not collapse into those aliases still shared the same recent point. 3M was -8.33% from 72.0 on 2026-05-30. 2M was +1.54% from 65.0 on 2026-06-27. 6M was +13.79% from 58.0 on 2026-02-28. 9M was -25.0% from 88.0 on 2025-11-29. 18M was +8.2% from 61.0 on 2025-03-01. YTD was +13.79% from 58.0 on 2026-01-03. QTD was +10.0% from 60.0 on 2026-07-04. Same 66.0, nine different baselines. For comma-separated sources in one get_growth body, see the multi-source growth API.
One REST or MCP body needs source and keyword. percent_growth is optional. The MCP tool name is get_growth. REST mode is get_growth (alias growth).
{
"mode": "get_growth",
"source": "google search",
"keyword": "nike"
}
{
"mode": "get_growth",
"source": "google search",
"keyword": "nike",
"percent_growth": ["7D", "1W", "12M", "1Y", "YTD", "MTD", "QTD", "5Y"]
}
{
"mode": "get_growth",
"source": "amazon",
"keyword": "air fryer",
"percent_growth": ["7D", "1W", "14D", "30D", "1M", "12M"]
}
Preset strings on MCP are 7D, 1W, 14D, 2W, 30D, 1M, 2M, 3M, 6M, 9M, 12M, 1Y, 18M, 24M, 2Y, 36M, 3Y, 48M, 4Y, 60M, 5Y, MTD, QTD, and YTD. Named {name, recent, baseline} objects are REST-only; that shape is documented on the custom date growth API. Each successful row carries period, growth, direction, recent_date, baseline_date, recent_value, and baseline_value. Failed presets stay in results with status error rather than aborting the call. metadata.calculations_completed counted 13 on the nike thirteen-window call and 1 on the default call.
collapsed_range means recent and baseline snapped to the same stored point. Amazon air fryer in this pull had 49 monthly points ending 2026-07-31. 7D, 1W, and 14D each returned error collapsed_range with message "Recent and baseline resolved to the same data point; not enough history for this preset". 30D and 1M both succeeded on 2026-07-31 versus 2026-06-30: index 51.5 versus 57.1, -9.81%, volumes 5,577,980 versus 6,178,129, volume growth -9.71%. 12M was -30.31% from 73.9 / 7,994,479 on 2025-07-31. metadata.all_successful was false because of the three short windows.
Steam Elden Ring used 54 monthly points ending 2026-08-01. 7D and 14D collapsed. Wikipedia ChatGPT (returned as Chatgpt) used 45 monthly points ending 2026-08-01. 7D and 14D collapsed there too. 30D on Wikipedia was -51.58% index (23.0 versus 47.5) and -51.51% volume (3,188 versus 6,574 page views). 12M was -71.95% index (23.0 versus 82.0) and -71.92% volume (3,188 versus 11,352).
app downloads on com.openai.chatgpt did not collapse. That series had 167 points and a recent_date of 2026-09-01, the newest clock in this session. 7D printed 6.2 / 4,506,151 versus 6.9 / 4,975,458 on 2026-08-24, -10.14% index and -9.43% volume. 14D was -12.68% from 7.1 / 5,123,149 on 2026-08-18. 30D flipped sign: +87.88% from 3.3 / 2,413,090 on 2026-08-01. 12M was -10.14% from 6.9 / 5,040,469 on 2025-09-04. A 7D job that mixes Amazon with Android downloads will look broken on Amazon and fine on the bundle ID. For Amazon search without the short-window trap, see Amazon search trends.
Steam Elden Ring on 2026-09-02 printed opposite signs for index and peak-player volume on the same dates. 30D index went from 1.9 on 2026-07-01 to 1.8 on 2026-08-01, -5.26%, while volume went from 46,694 to 52,385, +12.19%. 12M index went from 2.1 on 2025-08-01 to 1.8, -14.29%, while volume went from 50,646 to 52,385, +3.43%.
The 0-100 Steam index is not a rescaled copy of concurrent players. Publishing only growth hides the player count. Publishing only volume_growth hides the index. google search nike in the same session omitted volume_growth entirely, with volume_growth_omitted_reason set to "volume is derived from the trend value for this source, not an independent measurement". Treat 27,100,000 on that nike row as a derived label, not a query census. google shopping air fryer returned neither volume nor that reason field.
Read volume_available, volume_estimated when present, and both percent fields before ranking a source as up or down. Wikipedia ChatGPT kept index and page views aligned in this pull (-51.58% versus -51.51% on 30D). Steam did not.
The pull ran on 2026-09-02. nike google search still ended on 2026-08-29. MTD therefore used baseline 2026-08-01, the first day of the month that holds the latest weekly point, and printed 0.0% against 66.0. That is August month-to-date on a series that has not published a September row yet. It is not "September 2 versus September 1".
YTD used 2026-01-03, not January 1. QTD used 2026-07-04, not July 1. Weekly google search snapped those calendar anchors onto stored Saturdays. 12M used 2025-08-30, one day off a clean year, and matched 1Y exactly. A named REST YoY window only duplicates 12M when the requested dates already sit on that pair; that snap behavior is on the custom-date page, not in these MCP string presets.
amazon air fryer 30D used 2026-07-31 versus 2026-06-30, a full month behind the google search clock. Steam and Wikipedia 30D used 2026-08-01 versus 2026-07-01. app downloads 30D used 2026-09-01 versus 2026-08-01. Four sources, four "30D" calendars. metadata.total_data_points in this pull was 261 for google search, 260 for google shopping, 167 for app downloads, 54 for steam, 49 for amazon, and 45 for Wikipedia. For ranked live boards instead of these windows, see get_top_trends pagination.
Docs price get_growth per source plus keyword. The thirteen-window nike call and the default 12M call are both one unit on google search plus nike. Extra percent_growth strings do not add units. A comma-separated source list is the exception: that is one HTTP round trip and one billed unit per source, documented on the multi-source page.
Free covers 100 requests per month. Starter is $19 for 1,000. Pro is $49 for 5,000. Business is $199 for 25,000. Annual billing saves 20%. Failed presets such as amazon 7D still occupy a result row; confirm whether a collapsed window is billed as a successful 2xx on the account dashboard rather than guessing from all_successful false. Same sources on every plan. Check current pricing before locking a budget.
MCP takes the preset strings listed above. REST accepts those strings and, separately, named date objects. Do not send a date object to MCP and expect the custom-date page's snap fields. One account key covers both transports.
FAQ