Skip to main content
Glama

Get GDELT Coverage Breakdown

gdelt_get_coverage_breakdown
Read-only

Break down news coverage volume over time by source language or source country, returning a multi-series time series (one series per language or country). Shows which countries or languages drove early vs. late coverage — useful for tracing how a story propagated geographically or across language communities. Returns up to 10 series by total volume and aggregates the rest into an "Other" bucket, naming every series it folded in there under otherSeriesLabels — pass any of those labels back as the series input to get that series complete, ranked or not. Values are normalized: each point is the topic's share of media output, not an absolute article count. Small media markets with concentrated coverage therefore rank above large markets with diverse output — a high value means the topic dominated that source's coverage, not that it published the most articles. Use breakdownBy "country" with the signal-detection chain to map geographic attention, or "language" to detect non-English media surges.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
queryYesSearch query using GDELT syntax. Same operators as gdelt_search_articles: phrases, boolean OR, sourcecountry:, sourcelang:, domain:, theme:.
seriesNoExact series labels to additionally return in full, e.g. ["Portuguese", "Vietnamese"]. Take them verbatim from otherSeriesLabels (the series folded into "Other") or topSeries[].label in a response, or from the label list an unknown_series error prints. Each one comes back complete under selectedSeries, on top of the usual top-10 overview; a label that matches nothing is rejected rather than silently skipped. Omit to get the overview alone.
timespanNoTime window relative to now, minimum "15min"; other examples: "24h", "7d", "1m". Ignored when startDatetime/endDatetime are set. Maximum 3 months.
breakdownByYesBreakdown dimension: "language" for source language time series, "country" for source country time series.
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
errorNoPresent when the call failed. Absent on success.
noticeNoRecovery hint when no breakdown data was returned. Absent on successful responses.
topSeriesNoTop 10 series by total coverage volume.
totalCountNoTotal number of series returned before truncation to top 10.
breakdownByNoBreakdown dimension used for this response.
endDatetimeNoEchoed end datetime when provided (YYYYMMDDHHMMSS).
startDatetimeNoEchoed start datetime when provided (YYYYMMDDHHMMSS).
dateResolutionNoTemporal resolution of data points — 15min, hour, or day.
effectiveQueryNoEchoed query string for use in follow-up calls.
selectedSeriesNoComplete, untruncated time series for each label requested via the series input, in the order requested. Omitted when series was not supplied.
otherAggregatedNoCombined time series for all series beyond the top 10. Omitted when all series fit.
otherSeriesLabelsNoLabel of every series folded into otherAggregated, ranked by total volume — the identities the "Other" bucket would otherwise dissolve. Pass any of them to the series input to retrieve that series' complete data. Omitted when all series fit in the top 10.

TDQS

A4.7/5.0
Behavior5/5

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

The description adds substantial behavioral context beyond the readOnlyHint/openWorldHint annotations: the top-10-by-volume bucketing into 'Other', the otherSeriesLabels mechanics, rejection of unmatched series labels rather than silent skipping, and the normalization caveat that values are share of media output rather than absolute article counts. No statement contradicts the annotations.

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?

The description is long but dense: virtually every sentence adds operational value, from bucketing behavior to normalization interpretation to breakdownBy guidance. The core scope is front-loaded. The only minor weakness is the somewhat opaque 'signal-detection chain' reference, but on the whole the length is justified by the tool's behavioral complexity.

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?

Given that an output schema exists, the description covers the remaining operational concerns: what the series represent, how bucketing works, how to interpret normalized values, how to retrieve full series, and when to choose country vs language. Nothing an agent needs in order to select and invoke the tool correctly appears to be missing.

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

Parameters5/5

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

Although schema coverage is 100%, the description enriches the series parameter with operational instructions: take labels verbatim from otherSeriesLabels, topSeries[].label, or error lists; pass them back to get complete series under selectedSeries; and unmatched labels are rejected. This goes well beyond the schema's generic 'exact series labels' phrasing.

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-resource pairing: 'Break down news coverage volume over time by source language or source country.' It also specifies the output shape (multi-series time series) and names a concrete analytical use case ('tracing how a story propagated geographically'), which distinguishes it from the sibling gdelt_get_coverage_timeline.

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?

The description provides explicit selection guidance at the end: use breakdownBy 'country' with the signal-detection chain to map geographic attention, or 'language' to detect non-English media surges. It does not explicitly name sibling alternatives or state when not to use this tool, so it falls just short of full exclusion guidance.

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.