Pass source google search for a weekly Search interest series, or source news volume for an article-count series. Rank on type Google Trends is a different tool.
Live data as of 2026-10-18
Source google search on get_growth and get_time_series returns a weekly 0-100 Google Search interest series for one phrase. Source news volume returns a weekly 0-100 mention-count series for the same phrase, with an independent volume field of article counts and with series field datatype instead of source. Both pulls on October 18, 2026 used the string tesla. Google Search held 261 weekly points from 2021-10-23 through 2026-10-17 and closed 79.0 with series volume 13986272. News volume held 262 weekly points from 2021-10-16 through 2026-10-17 and closed 8.0 with 1627 articles. The 12M window moved in opposite directions: Google Search plus 92.68 percent from 41.0, news volume minus 37.98 percent from 12.9. Live boards use type Google Trends, not those source strings.
The October 18, 2026 pull is the split that still matters next month: same close Saturday, then opposite 12M signs. get_time_series for tesla on source google search returned 261 weekly points from 2021-10-23 (value 34, volume 6019408) through 2026-10-17 (value 79, volume 13986272). Peak 83 sat on 2025-03-15 at volume 14694438. The series field is source google search. Growth metadata printed total_data_points 261.
MCP get_time_series for tesla on source news volume returned 262 weekly points from 2021-10-16 (value 7.8, volume 1599) through 2026-10-17 (value 8.0, volume 1627). Peak 100 sat on 2022-04-30 at volume 20423. The series field is datatype news volume. Growth metadata printed total_data_points 262. Peak week is not shared. Search peaked in March 2025. News volume peaked in April 2022. Search on 2022-04-30 was 44 at volume 7789822, not the Search peak.
Growth windows line up by preset name and split by sign on 12M and YTD. Google Search tesla 7D matched 1W: 79.0 from 32.0, plus 146.88 percent, recent_date 2026-10-17, baseline 2026-10-10. 14D: 79.0 from 40.0, plus 97.5 percent. 30D matched 1M: 79.0 from 43.0, plus 83.72 percent. 3M was plus 102.56 percent from 39.0 on 2026-07-18. 12M was plus 92.68 percent from 41.0 on 2025-10-18. YTD was plus 113.51 percent from 37.0 on 2026-01-03. News volume tesla 7D matched 1W: 8.0 from 0.1, plus 7900.0 percent. 14D: 8.0 from 8.1, minus 1.23 percent. 30D matched 1M: 8.0 from 0.2, plus 3900.0 percent. 3M was minus 25.93 percent from 10.8 on 2026-07-18. 12M was minus 37.98 percent from 12.9 on 2025-10-18. YTD was minus 62.44 percent from 21.3 on 2026-01-03.
| Window | Search close | Search growth | Volume close | Volume growth |
|---|---|---|---|---|
| 7D / 1W | 79.0 from 32.0 | +146.88% | 8.0 from 0.1 | +7900.0% |
| 14D | 79.0 from 40.0 | +97.5% | 8.0 from 8.1 | -1.23% |
| 30D / 1M | 79.0 from 43.0 | +83.72% | 8.0 from 0.2 | +3900.0% |
| 3M | 79.0 from 39.0 | +102.56% | 8.0 from 10.8 | -25.93% |
| 12M | 79.0 from 41.0 | +92.68% | 8.0 from 12.9 | -37.98% |
| YTD | 79.0 from 37.0 | +113.51% | 8.0 from 21.3 | -62.44% |
Later reprints of Search on the same morning moved. REST get_growth printed close 81.0 from 33.0 on 7D, plus 145.45 percent, then a later REST comma printed 82.0 from 35.0, plus 134.29 percent. A later MCP default-12M call printed 82.0 from 43.0, plus 90.7 percent. REST omit-percent_growth on news volume still printed 8.0 from 12.9, minus 37.98 percent, 1627 articles, 262 points. Quote the first dedicated MCP table for the comparison. Quote later Search closes as later Search closes. News volume did not ride that rescale.
Follow-up for Search history lives on the Google search data page. Article-count history lives on news volume data. Google News search, a third weekly 0-100 series with no volume, is a separate source on Google Search vs Google News.
News volume tesla 7D plus 7900.0 percent is arithmetic on a trough, not a 79-times jump in coverage. Baseline 2026-10-10 sat at 0.1 with 26 articles. Close 2026-10-17 sat at 8.0 with 1627 articles. Volume growth on that window was plus 6157.69 percent, from 26 to 1627. The index move and the article-count move are different percents because the 0-100 column is not a raw count.
The neighboring 14D window is the check. Same close 8.0, baseline 8.1 on 2026-10-03, minus 1.23 percent, article counts 1627 versus 1657, volume growth minus 1.81 percent. A caller who stores only 7D will print a spike. A caller who also stores 14D will print a flat week after a hole. Read the baseline date. A 0.1 week is a hole in the series, not a typical floor.
News volume can print a true zero. The tesla series sat at 0.0 with volume 0 on 2025-06-21 and again on 2025-06-28. Google Search on those Saturdays sat at 35 and 39. A zero week is missing coverage in this source, not a missing Search week. Point-to-point growth that lands a baseline on one of those zeros will explode or fail depending on how the handler treats a zero divisor. This pull's 7D baseline was 0.1, not 0.0, so the percent printed.
Dedicated Search growth for other names did return. bitcoin closed 19.0, 7D minus 13.64 percent from 22.0, 12M minus 67.24 percent from 58.0, 261 points, no volume keys. nike closed 51.0, 7D plus 2.0 percent from 50.0, 12M minus 12.07 percent from 58.0, estimated volume 19200000.0. MCP get_growth for bitcoin and nike on source news volume returned CloudFront HTTP 504 HTML. REST retries for nvidia and openai on that source returned 504 as well. Quote those timeouts. Do not invent a 12M news volume row for those names from a 504.
Google Search tesla printed estimated volume in the millions. News volume tesla printed 1627 articles. Those are two different units on the same keyword. A comma-separated get_growth call is supposed to join them. On this pull, MCP did not.
{"mode": "get_growth", "source": "google search, news volume", "keyword": "tesla", "percent_growth": ["7D", "30D", "12M"]}
That MCP comma call on October 18, 2026 returned sources_requested 2, sources_processed 2, sources_successful 1, and sources_failed 1. The Search row matched the dedicated 7D, 30D, and 12M prints from the first MCP table (close 79.0). The news volume row printed status unavailable and message Source did not respond in time. trend_analysis then counted only the successful source: uptrend_ratio 1/1, uptrend_percentage 100.0, total_sources_analyzed 1. A timeout is not an uptrend vote. It is a missing vote.
volume_weighted_growth was 146.88 with has_volume_data true, sources_with_volume 1, weight_coverage 1/1 sources, and total_volume 14000000.0. The only weighted row was Google Search, at 100 percent of that volume, using Search 7D growth plus 146.88. News volume plus 7900.0 percent never entered, because the mixer never received it. Search 12M plus 92.68 percent never entered either. volume_growth on Search was null, with the reason that volume is derived from the trend value. The mixer still used the index growth from the volume-bearing source.
REST then printed a different mixer. The first REST comma on 7D and 12M returned sources_successful 2 and sources_failed 0. trend_analysis printed uptrend_ratio 2/2. volume_weighted_growth was 146.15 with sources_with_volume 2, weight_coverage 2/2 sources, and total_volume 13901627.0. Search took 13900000.0, 99.99 percent of that total, using Search 7D growth plus 145.45 at close 81.0. News volume took 1627.0, 0.01 percent, using growth 6157.69. That 6157.69 is the article-count volume_growth from the dedicated 7D window, not the 7900.0 index percent. Mixing Search millions with 1627 articles makes the mention series a rounding error in the weighted number, even when both sources succeed.
A later REST comma on the same body marked news volume unavailable again and reprinted Search at 82.0, 7D plus 134.29 percent, volume_weighted_growth 134.29, weight_coverage 1/1 sources. Dedicated REST get_growth for tesla on source news volume with 7D and 12M returned CloudFront HTTP 504. REST with percent_growth omitted then printed the default 12M row and matched the MCP 12M: 8.0 from 12.9, minus 37.98 percent, 1627 articles. A timeout on one REST body is not proof the source is missing. Retry a dedicated call.
get_time_series rejects the comma. Source google search, news volume returned HTTP 200 with envelope statusCode 400, error invalid_source, message 'google search, news volume' is not a valid source., and listed 16 keyword sources with no all. One source per series call. Two sources belong on get-growth.
Two strings, two tools. REST uses mode get_growth or get_top_trends. MCP uses the matching tool names. Google Search history lives on the Google search data page. Article-count follow-up lives on news volume data. Headline follow-up is type Google News Top News, not source news volume.
{"mode": "get_growth", "source": "google search, news volume", "keyword": "tesla", "percent_growth": ["30D", "12M"]}
{"mode": "get_time_series", "source": "google search", "keyword": "tesla"}
{"mode": "get_time_series", "source": "news volume", "keyword": "tesla"}
{"mode": "get_top_trends", "type": "Google Trends"}
The MCP equivalents are get_growth(keyword="tesla", source="google search, news volume", percent_growth=["30D", "12M"]), get_time_series(keyword="tesla", source="google search"), get_time_series(keyword="tesla", source="news volume"), and get_top_trends(type="Google Trends"). MCP 1W matched 7D on tesla for both sources on the first dedicated pull. MCP 1M matched 30D on both.
REST type google search (the keyword source string, lowercase) returned HTTP 200, echoed type Google Trends, as_of_ts 2026-10-18T06:01:35.388875+00:00, and matched rj mitte at rank 1. REST type news volume returned HTTP 200 with envelope statusCode 400, error invalid_request, message Unknown type 'news volume', plus 24 valid feed labels. llms.txt still describes feed labels as case-sensitive. The live handler accepted google search as an alias on October 18, 2026 and rejected news volume. Prefer the canonical Google Trends spelling in stored configs. Do not pass source news volume as a feed type.
get_growth with source Google Trends and keyword tesla returned HTTP 200 with envelope statusCode 400, error invalid_source, message "'google trends' is not a valid source.", plus 17 names including all. The handler lowercased the rejected type string. It did not map it to source google search. get_time_series on source Google Trends failed the same way and listed 17 names including all. The comma series 400 on google search, news volume listed 16 names and omitted all. The rejected string changes the valid-source list.
REST source news_volume (one token, no space) returned HTTP 200 with envelope statusCode 400, error invalid_source, message "'news_volume' is not a valid source.", and listed 17 names including all. The space is required. Store news volume.
REST omitting type is a different 400. POST https://api.trendsmcp.ai/api with mode get_top_trends and limit 1, no type, returned HTTP 200 with envelope statusCode 400, error invalid_request, message The 'type' parameter is required, then the same 24-name list. llms.txt still names that miss missing_parameter. Read statusCode inside the JSON, not only the HTTP line.
get_top_trends MCP pricing is 1 credit per 10 requested rows, max 10 credits per call. REST counts 1 request per call. Free boards still cap at the top 10. Keyword follow-up stays on source google search or source news volume. The live board stays on type Google Trends.
FAQ