Grounding LLM Answers in Real-Time Google Trends Data

LLMs guess about what's trending from stale training data. Wire an agent to Serply's Trends endpoints and it can answer with today's actual numbers.

Profile picture of Serply
Serply
Line chart of rising search interest next to a chat interface

Ask an LLM “is X trending right now” and you’ll get a confident, well-written answer. You’ll also get an answer that’s wrong more often than it should be, because the model doesn’t actually know what’s happening today — it knows what was happening whenever its training data was collected, and it will present that as current fact unless you give it a reason not to.

This is one of the more avoidable failure modes in AI agent design. “What’s trending” and “has interest in this topic gone up or down” are exactly the kind of question you shouldn’t ask a language model to reason about from memory — they’re time-series questions with a real, checkable answer, and there’s an API for that. This post walks through wiring an agent up to Serply’s Google Trends endpoints so it grounds those answers in live data instead of pattern-matching against however the world looked at training time.

A language model’s sense of “now” freezes the moment its training data was collected. Ask it what’s trending and it will, without hedging, describe search behavior from months or years ago as if it’s current — because from the model’s perspective, nothing has happened since. There’s no internal signal telling it that its information has gone stale.

That’s fundamentally different from a knowledge gap the model can admit to. It’s not that it doesn’t know — it’s that it thinks it knows, and it’s not wrong about the mechanism, just the moment. The fix isn’t better prompting. It’s giving the agent a tool call that hits a live data source before it answers, the same way you’d ground a factual claim with a search call instead of trusting recall.

Serply exposes a handful of Google Trends endpoints under https://api.serply.io/v1/, all authenticated with an X-Api-Key header (see the authentication guide if you haven’t set that up yet):

  • GET /v1/trends/{query} — general trends search for a keyword. If you’ve hit this endpoint with a bare keyword in the past and gotten an empty result back, that was a known parsing bug on our end that’s since been fixed — keyword-only queries now return real trend data reliably.
  • GET /v1/trend/interest_over_time/{query} — time-series interest data for a specific query, the endpoint you want for “has interest in this been rising or falling.”
  • GET /v1/trend/trending_today/{geo} — today’s trending searches for a geography, e.g. US.
  • GET /v1/trend/trending_realtime/{geo} — real-time trending searches for a geography, for a more moment-to-moment view than “today’s” aggregate.
  • GET /v1/trend/related_topics/{query} — related topics for a given query, useful for expanding a narrow question into adjacent context.

A quick note on honesty here: these endpoints aren’t documented yet in Serply’s public API reference with a locked-down response schema, so rather than invent field names that might not match what you actually get back, the examples below deliberately stay generic (response.json(), then work with whatever keys come back) instead of hardcoding a specific shape. Before you ship this in production, hit the endpoint yourself, inspect the real response, and pin down the exact fields you’re relying on — don’t copy field names out of a blog post as gospel. What you can rely on conceptually: trending_today/trending_realtime give you back a list of trending query strings for the geography you asked about, and interest_over_time gives you back a time-indexed series of relative interest scores for your query — that shape is stable even if the exact key names take some verification.

Building the tool functions

Here’s a minimal pair of Python functions you’d expose as tools to an LLM agent — one for “what’s trending now,” one for “how has this specific thing trended over time”:

import requests

API_KEY = "YOUR_API_KEY"
BASE_URL = "https://api.serply.io/v1"


def get_trending_now(geo: str = "US") -> dict:
    """Fetch today's trending searches for a geography (e.g. 'US', 'GB', 'IN')."""
    response = requests.get(
        f"{BASE_URL}/trend/trending_today/{geo}",
        headers={"X-Api-Key": API_KEY},
    )
    response.raise_for_status()
    return response.json()


def get_interest_over_time(query: str) -> dict:
    """Fetch time-series interest data for a search query."""
    response = requests.get(
        f"{BASE_URL}/trend/interest_over_time/q={requests.utils.quote(query)}",
        headers={"X-Api-Key": API_KEY},
    )
    response.raise_for_status()
    return response.json()

Wire both into your agent’s tool set, and a question like “what’s trending in the US right now, and has interest in heat pumps been going up or down?” turns into two tool calls instead of one hallucinated paragraph:

trending = get_trending_now("US")
interest = get_interest_over_time("heat pumps")

# Hand both payloads to the model as tool results, and let it
# synthesize the answer from what actually came back — not from
# what it assumes is probably still true.

The important design choice here isn’t the code — it’s making the trends lookup a required step in the agent’s reasoning path for this class of question, rather than an optional tool it might reach for. If your agent framework supports it, route “is X trending” / “has interest in Y changed” style questions through a system prompt rule that says something like: “For any question about current search trends or interest over time, you must call get_trending_now or get_interest_over_time before answering — do not answer from prior knowledge.” That one line does more to fix the hallucination problem than any amount of “be accurate” boilerplate.

A single trending list is often too narrow to be useful on its own — “X is trending” doesn’t tell your user why, or what’s adjacent to it. Pairing trending_today with related_topics lets an agent build a fuller picture in one pass: pull the day’s trending list, then for the entries that look relevant to the user’s question, pull related topics to give the model something to reason about beyond a bare keyword.

def get_related_topics(query: str) -> dict:
    response = requests.get(
        f"{BASE_URL}/trend/related_topics/q={requests.utils.quote(query)}",
        headers={"X-Api-Key": API_KEY},
    )
    response.raise_for_status()
    return response.json()

An agent that chains trending_today → related_topics for the top few results can answer follow-up questions (“why is that trending?”, “what else is related?”) without a second round-trip to the user, because it already has the adjacent context loaded.

The pattern generalizes

Trends is a clean example, but the underlying pattern applies to any “what’s happening right now” question you’d otherwise leave to a language model’s memory: news (Serply’s /v1/news endpoint), live search results, price data. Any time a question has a real, checkable, time-sensitive answer, the right move is a tool call, not a better prompt. Grounding isn’t a nice-to-have for these questions — it’s the only way the answer can be correct.

If you’re building an agent that needs to reason about current events, trending topics, or anything else time-sensitive, start with Serply’s API and treat “what does the model already believe” as a red flag, not a shortcut.