Skip to main content
Glama

Get GDELT Coverage Timeline

gdelt_get_coverage_timeline
Read-only

Retrieve a time series showing when news coverage of a topic spiked, or how average tone shifted over time. Use mode "volume" for normalized coverage intensity (% of all global coverage per timestep). Use mode "volume_with_articles" for the same signal plus the top articles that drove each spike — this is the primary signal-detection mode: a single call reveals both the spike and its cause, avoiding a follow-up gdelt_search_articles call. Use mode "tone" for average sentiment score per timestep (negative = hostile/fearful, positive = celebratory). Date resolution is inferred from returned intervals: 15 minutes or hours for short windows, days for longer ones. In volume_with_articles mode the text surface shows the first 3 article links per timestep next to that timestep's true article count; name a timestep's date in points to render its full list. Note: DOC API covers only the last 3 months.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
modeNoTimeline mode: "volume" returns normalized coverage % per timestep, "volume_with_articles" returns volume plus top articles per spike (best for signal detection), "tone" returns average sentiment score per timestep.volume
queryYesSearch query using GDELT syntax. Same operators as gdelt_search_articles: phrases, boolean OR, sourcecountry:, sourcelang:, domain:, theme:, tone<.
pointsNoTimestep dates whose complete article list should be rendered in the text surface, e.g. ["2024-01-05T12:00:00Z"]. Take them verbatim from series[].data[].date in a prior response, or from the list an unknown_point error prints. Only affects volume_with_articles rendering — every timestep already carries its full article list in structuredContent regardless. Timesteps not named here show their first 3 links; a date matching no timestep is rejected rather than silently ignored.
timespanNoTime window relative to now, minimum "15min"; other examples: "24h", "7d", "1m". Ignored when startDatetime/endDatetime are set. Maximum 3 months.
smoothingNoSmoothing window in timesteps (0 = none, 1–5 = moving average width). Reduces noise for spotty topics.
endDatetimeNoEnd datetime in GDELT format YYYYMMDDHHMMSS — exactly 14 digits, no separators (e.g. 20240131235959). Must pair with startDatetime; supplying only one of the two is rejected.
startDatetimeNoStart datetime in GDELT format YYYYMMDDHHMMSS — exactly 14 digits, no separators (e.g. 20240101000000). Must pair with endDatetime; supplying only one of the two is rejected.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
modeNoTimeline mode used for this response.
errorNoPresent when the call failed. Absent on success.
noticeNoRecovery hint when no timeline data was returned. Absent on successful responses.
seriesNoOne or more time series (typically one for volume/tone, one per label for breakdowns).
totalCountNoTotal number of data points across all series.
endDatetimeNoEchoed end datetime when provided (YYYYMMDDHHMMSS).
startDatetimeNoEchoed start datetime when provided (YYYYMMDDHHMMSS).
dateResolutionNoTemporal resolution of the data points — 15min, hour, or day.
effectiveQueryNoEchoed query string for use in follow-up calls.
expandedPointsNoTimestep dates whose full article list is rendered in the text surface instead of the first 3, echoing the points input. Omitted when points was not supplied. Purely a rendering concern — structuredContent carries every article for every timestep either way.

TDQS

A4.7/5.0
Behavior5/5

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

Annotations provide readOnlyHint and openWorldHint, and the description adds substantial behavioral context beyond that: normalized global coverage percentages, inferred date resolution, text-surface rendering of only the first 3 article links unless points is specified, and the 3-month DOC API limitation. It also clarifies that volume_with_articles avoids a follow-up search, which is important workflow behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is dense but every sentence earns its place: purpose, mode selection, resolution behavior, rendering behavior, and a critical time-boundary caveat. It is front-loaded with the core purpose and then builds outward; no filler or redundant restatement of the title.

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?

For a tool with 7 parameters, rich mode semantics, and a dedicated output schema, the description covers all the essential operational knowledge: mode intent, time resolution inference, points rendering behavior, and the 3-month API limit. Since an output schema exists, the description does not need to document return fields, and annotations already cover the read-only/open-world safety profile.

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 coverage is 100%, so the baseline is 3. The description earns a 4 by adding meaning beyond the schema: it explains the real-world meaning of volume ('% of all global coverage per timestep'), designates volume_with_articles as the primary signal-detection mode, and clarifies that the DOC API only covers the last 3 months. This helps an agent choose mode values rather than merely filling them.

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 opens with a specific verb and resource: 'Retrieve a time series showing when news coverage of a topic spiked, or how average tone shifted over time.' It clearly distinguishes the timeline nature of this tool from sibling tools like gdelt_get_coverage_breakdown or gdelt_get_tone_distribution, and even names gdelt_search_articles as the alternative it can avoid.

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

Usage Guidelines4/5

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

It gives explicit mode-by-mode guidance ('Use mode "volume" for...', 'Use mode "volume_with_articles" for...', 'Use mode "tone" for...') and highlights the primary signal-detection workflow while noting the DOC API 3-month limit. It does not explicitly contrast with sibling tools like gdelt_get_coverage_breakdown or gdelt_get_tone_distribution, so it stops just short of complete alternative routing.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.6/5.0
Disambiguation5/5

Each tool serves a distinct purpose: search articles vs. search TV, coverage timelines vs. breakdowns vs. tone distributions, and TV-specific tools for clips, context, trending, and station listing. Even overlapping functions like get_coverage_timeline and get_tone_distribution are clearly differentiated by description.

Naming Consistency5/5

All tools follow the consistent pattern 'gdelt_<verb>_<object>' using snake_case, with verbs limited to get, search, and list. The naming is predictable and uniform, with no mixed conventions.

Tool Count5/5

Nine tools is a well-scoped number for the GDELT domain, covering both text and TV news APIs without redundancy. Each tool adds clear value, and the count is within the ideal 3-15 range.

Completeness5/5

The tool surface covers the core workflows: searching articles and TV transcripts, obtaining coverage timelines and breakdowns, analyzing tone distributions, retrieving TV clips and context, and listing stations. There are no obvious dead ends or missing operations for the stated purpose.