gdelt-mcp-server
Server Details
Search and analyze global news coverage and US TV transcripts via the GDELT Project APIs.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
- Repository
- cyanheads/gdelt-mcp-server
- GitHub Stars
- 4
- Server Listing
- @cyanheads/gdelt-mcp-server
Available Tools
9 toolsgdelt_get_coverage_breakdownGet GDELT Coverage BreakdownARead-onlyInspect
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.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Search query using GDELT syntax. Same operators as gdelt_search_articles: phrases, boolean OR, sourcecountry:, sourcelang:, domain:, theme:. | |
| series | No | Exact 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. | |
| timespan | No | Time window relative to now, minimum "15min"; other examples: "24h", "7d", "1m". Ignored when startDatetime/endDatetime are set. Maximum 3 months. | |
| breakdownBy | Yes | Breakdown dimension: "language" for source language time series, "country" for source country time series. | |
| endDatetime | No | End 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. | |
| startDatetime | No | Start 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
| Name | Required | Description |
|---|---|---|
| error | No | Present when the call failed. Absent on success. |
| notice | No | Recovery hint when no breakdown data was returned. Absent on successful responses. |
| topSeries | No | Top 10 series by total coverage volume. |
| totalCount | No | Total number of series returned before truncation to top 10. |
| breakdownBy | No | Breakdown dimension used for this response. |
| endDatetime | No | Echoed end datetime when provided (YYYYMMDDHHMMSS). |
| startDatetime | No | Echoed start datetime when provided (YYYYMMDDHHMMSS). |
| dateResolution | No | Temporal resolution of data points — 15min, hour, or day. |
| effectiveQuery | No | Echoed query string for use in follow-up calls. |
| selectedSeries | No | Complete, untruncated time series for each label requested via the series input, in the order requested. Omitted when series was not supplied. |
| otherAggregated | No | Combined time series for all series beyond the top 10. Omitted when all series fit. |
| otherSeriesLabels | No | Label 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
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.
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.
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.
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.
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.
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.
gdelt_get_coverage_timelineGet GDELT Coverage TimelineARead-onlyInspect
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.
| Name | Required | Description | Default |
|---|---|---|---|
| mode | No | Timeline 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 |
| query | Yes | Search query using GDELT syntax. Same operators as gdelt_search_articles: phrases, boolean OR, sourcecountry:, sourcelang:, domain:, theme:, tone<. | |
| points | No | Timestep 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. | |
| timespan | No | Time window relative to now, minimum "15min"; other examples: "24h", "7d", "1m". Ignored when startDatetime/endDatetime are set. Maximum 3 months. | |
| smoothing | No | Smoothing window in timesteps (0 = none, 1–5 = moving average width). Reduces noise for spotty topics. | |
| endDatetime | No | End 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. | |
| startDatetime | No | Start 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
| Name | Required | Description |
|---|---|---|
| mode | No | Timeline mode used for this response. |
| error | No | Present when the call failed. Absent on success. |
| notice | No | Recovery hint when no timeline data was returned. Absent on successful responses. |
| series | No | One or more time series (typically one for volume/tone, one per label for breakdowns). |
| totalCount | No | Total number of data points across all series. |
| endDatetime | No | Echoed end datetime when provided (YYYYMMDDHHMMSS). |
| startDatetime | No | Echoed start datetime when provided (YYYYMMDDHHMMSS). |
| dateResolution | No | Temporal resolution of the data points — 15min, hour, or day. |
| effectiveQuery | No | Echoed query string for use in follow-up calls. |
| expandedPoints | No | Timestep 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
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.
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.
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.
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.
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.
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.
gdelt_get_tone_distributionGet GDELT Tone DistributionARead-onlyInspect
Get the tonal distribution of articles matching a query as a histogram (bins approximately -30 to +30). Unlike a single average tone score, the histogram reveals whether coverage is uniformly negative, bimodal (some articles extremely positive and some extremely negative), or clustered near neutral. Each bin includes representative article URLs. Distinct from gdelt_get_coverage_timeline (mode: tone) — this is a snapshot distribution across all matching articles, not a time series. Use gdelt_get_coverage_timeline with mode "tone" to see how sentiment shifted over time.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Search query using GDELT syntax. Same operators as gdelt_search_articles: phrases, boolean OR, sourcecountry:, sourcelang:, domain:, theme:. | |
| timespan | No | Time window relative to now, minimum "15min"; other examples: "24h", "7d", "1m". Ignored when startDatetime/endDatetime are set. Maximum 3 months. | |
| endDatetime | No | End 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. | |
| startDatetime | No | Start 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
| Name | Required | Description |
|---|---|---|
| error | No | Present when the call failed. Absent on success. |
| notice | No | Recovery hint when no tone data was returned. Absent on successful responses. |
| summary | No | Summary statistics derived from the histogram. |
| histogram | No | Tone histogram sorted from most negative to most positive bin. |
| totalCount | No | Total number of articles across all histogram bins. |
| endDatetime | No | Echoed end datetime when provided (YYYYMMDDHHMMSS). |
| startDatetime | No | Echoed start datetime when provided (YYYYMMDDHHMMSS). |
| effectiveQuery | No | Echoed query string for use in follow-up calls. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint and openWorldHint, so the safety profile is covered. The description adds behavioral context beyond annotations: it explains the histogram bin range, notes that each bin includes representative article URLs, and clarifies that this is a snapshot distribution rather than a time series.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is slightly longer than necessary but every sentence earns its place: it defines the output type, explains the analytical value, mentions bin contents, and differentiates from the sibling tool. The key scoping statement is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With a rich output schema present and 100% parameter coverage, the description is complete for an agent to correctly invoke the tool. It adds the essential interpretive context (histogram semantics, bin contents, snapshot vs. time-series distinction) and names the relevant sibling, leaving no important gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents all four parameters. The description does not add new parameter meaning beyond what the schema already says, but it correctly references the query syntax without repeating the schema details. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Get the tonal distribution of articles matching a query as a histogram.' It clearly distinguishes itself from gdelt_get_coverage_timeline by explicitly contrasting a snapshot distribution with a time series, so an agent can tell them apart without opening schemas.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit usage context: it explains when the histogram is valuable (uniformly negative, bimodal, neutral clustering) and explicitly names the alternative tool and condition for choosing it ('Use gdelt_get_coverage_timeline with mode "tone" to see how sentiment shifted over time').
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
gdelt_get_tv_clipsGet GDELT TV ClipsARead-onlyInspect
Retrieve the top matching TV news clips (up to 3,000) for a query from the Internet Archive's Television News Archive. Each clip includes show name, station, air timestamp, a 15-second transcript excerpt, and a direct link to view the full one-minute clip. Use after gdelt_search_tv to read the actual transcript content driving a coverage spike. 3,000 is a hard per-call ceiling and GDELT offers no cursor: when a query fills it, split the run into narrower startDatetime/endDatetime windows — the response hands back the exact windows to use. Archive coverage spans 2009–October 2024.
| Name | Required | Description | Default |
|---|---|---|---|
| sort | No | Sort order: relevance (default), dateDesc (newest first), dateAsc (oldest first). | relevance |
| query | Yes | Search query for TV transcript content. Same TV operators as gdelt_search_tv: station:CNN, network:CBS, market:"National", show:"Anderson Cooper", context:"vaccine". | |
| stations | No | Station IDs to filter to (e.g. ["CNN", "FOXNEWS"]). The GDELT TV API requires at least one station — supply it here, or embed a station: selector directly in query. Omitting both is rejected; it does not fall back to all stations. Use gdelt_list_tv_stations to see valid IDs. | |
| timespan | No | Time window, e.g. "1m", "6m". Ignored when startDatetime/endDatetime are set. TV data spans 2009–October 2024. | |
| maxRecords | No | Maximum number of clips to return (1–3000). 3000 is GDELT's hard per-call ceiling, not a page size — there is no cursor past it, so a query that fills 3000 must be split into narrower startDatetime/endDatetime windows instead. | |
| endDatetime | No | End datetime in GDELT format YYYYMMDDHHMMSS — exactly 14 digits, no separators (e.g. 20200131235959). Must pair with startDatetime; supplying only one of the two is rejected. | |
| startDatetime | No | Start datetime in GDELT format YYYYMMDDHHMMSS — exactly 14 digits, no separators (e.g. 20200101000000). Must pair with endDatetime; supplying only one of the two is rejected. |
Output Schema
| Name | Required | Description |
|---|---|---|
| clips | No | Matching TV clips sorted per the sort parameter. |
| error | No | Present when the call failed. Absent on success. |
| notice | No | Disclosure that the maxRecords cap was reached and more clips may exist, naming the route to them — a higher maxRecords below the 3000 ceiling, or a narrower date window at it. Absent when the full result set fit under the cap. |
| totalCount | No | Number of clips returned. |
| effectiveQuery | No | Echoed query string for use in follow-up calls. |
| continuationWindows | No | The queried window halved, to re-run this query against one pair at a time when maxRecords is at its 3000 ceiling. The halves overlap by one second so no clip falls through the seam; a clip aired on that second can come back in both, so de-duplicate by archiveUrl. Absent unless the ceiling was reached with a window that is both known and wide enough to divide. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint and openWorldHint, so the bar for adding value is met substantially. The description discloses important behavior beyond annotations: 3,000 is a hard per-call ceiling, there is no cursor, queries that fill the limit must be split into narrower startDatetime/endDatetime windows, and the response supplies those exact windows. This is exactly the kind of operational behavior an agent needs to know.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but well-organized: purpose first, then result contents, then usage relationship, then the critical pagination limitation, then date coverage. Every sentence earns its place and there is no filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema and a rich parameter schema, the description covers the remaining operational essentials: the clip types returned, the 3,000 hard limit, the no-cursor pagination strategy with split windows, the correct placement after gdelt_search_tv, and the 2009–October 2024 coverage window. An agent has enough context to call this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters clearly. The description reinforces the 3,000-ceiling and no-cursor behavior and notes the response returns splitting windows, which adds useful context, but it does not need to explain individual parameters further. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action and resource: 'Retrieve the top matching TV news clips (up to 3,000) for a query from the Internet Archive's Television News Archive.' It also clarifies the tool's distinct role relative to gdelt_search_tv by explicitly saying it reads 'the actual transcript content driving a coverage spike,' so an agent can distinguish it from sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear when-to-use guidance: 'Use after gdelt_search_tv to read the actual transcript content driving a coverage spike.' It also explains the hard 3,000-ceiling behavior and how to handle overflow queries. However, it does not explicitly name sibling alternatives or state when not to use this tool, leaving some inference to the agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
gdelt_get_tv_contextGet GDELT TV ContextARead-onlyInspect
Get the top co-occurring words and phrases from TV news clips matching a query — the vocabulary framing a topic on television. Returns the most frequent non-stopword terms from matching clips, with relative frequency scores (0–100, where 100 = the query term itself). Use to understand narrative framing, identify related concepts mentioned alongside a topic, or generate follow-up search terms. TV data spans 2009–October 2024.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Search query for TV transcript content. Same TV operators as gdelt_search_tv: station:CNN, network:CBS, market:"National", show:"Anderson Cooper", context:"vaccine". | |
| stations | No | Station IDs to filter to (e.g. ["CNN", "FOXNEWS"]). The GDELT TV API requires at least one station — supply it here, or embed a station: selector directly in query. Omitting both is rejected; it does not fall back to all stations. Use gdelt_list_tv_stations to see valid IDs. | |
| timespan | No | Time window, e.g. "1m", "6m". Ignored when startDatetime/endDatetime are set. TV data spans 2009–October 2024. | |
| endDatetime | No | End datetime in GDELT format YYYYMMDDHHMMSS — exactly 14 digits, no separators (e.g. 20200131235959). Must pair with startDatetime; supplying only one of the two is rejected. | |
| startDatetime | No | Start datetime in GDELT format YYYYMMDDHHMMSS — exactly 14 digits, no separators (e.g. 20200101000000). Must pair with endDatetime; supplying only one of the two is rejected. TV data spans 2009–October 2024. |
Output Schema
| Name | Required | Description |
|---|---|---|
| error | No | Present when the call failed. Absent on success. |
| words | No | Co-occurring terms sorted by score descending. |
| notice | No | Recovery hint when no context was found. Absent on successful responses. |
| totalCount | No | Number of clips from which co-occurrences were computed. Absent when the upstream API does not return a clip count. |
| effectiveQuery | No | Echoed query string for use in follow-up calls. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark this read-only, so the description adds value by explaining the output: most frequent non-stopword terms with relative frequency scores where 100 equals the query term itself. It also discloses the TV data time span, which agents would not know from annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded with the core purpose, followed by useful output semantics and use cases. Every sentence contributes distinct information, and there is no filler or tautology.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the rich schema and output schema, the description sufficiently explains return semantics and intended use. It could mention the station requirement more prominently, but the schema already covers that detail, so the description is complete enough for an agent to call the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters including query operators, station requirements, and datetime constraints. The description adds no additional parameter-level meaning, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description states a specific verb and resource: get top co-occurring words/phrases from TV news clips. It clearly differentiates from siblings like gdelt_get_tv_clips and gdelt_get_tone_distribution by describing the output as vocabulary framing, not clips or tones.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says when to use it: understand narrative framing, identify related concepts, and generate follow-up search terms. It does not name alternative tools or state when not to use it, but the intended contexts are clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
gdelt_get_tv_trendingGet GDELT TV TrendingARead-onlyInspect
Retrieve trending topics, keywords, and phrases currently dominating US television news across national networks. No query required — returns the top memes of the present news cycle. Updated every 15 minutes. Note: the GDELT TV archive feed stopped updating around October 2024; results from this endpoint reflect that most-recent archived data rather than a live feed.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
| Name | Required | Description |
|---|---|---|
| error | No | Present when the call failed. Absent on success. |
| notice | No | Recovery hint when no trending topics were returned. Absent on successful responses. |
| topics | No | Trending topics sorted by score descending. |
| totalCount | No | Total number of trending topics returned. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint and openWorldHint annotations, the description discloses two important behavioral traits: the feed updates every 15 minutes and, critically, that the GDELT TV archive stopped updating around October 2024, so results are archived rather than live. This is substantial context an agent needs to interpret results correctly.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well structured: purpose first, then the no-query clarification, then update cadence, then the important archival caveat. Every sentence provides necessary information without padding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter tool with an output schema and readOnly/openWorld annotations, the description provides all essential context: what it returns, the no-query workflow, the update cadence, and the data freshness caveat. Nothing critical is missing for an agent to select and invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema covers 100% of that, so the baseline is 4. The description adds the relevant clarification that no query is required, which reinforces the no-parameter nature of the call.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Retrieve') and names the exact resource: trending topics, keywords, and phrases currently dominating US television news. It also clarifies there is no query required, which differentiates it clearly from the sibling search tools like gdelt_search_tv.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly states when to use the tool: when you want current trending memes with no query. The explicit 'No query required' communicates the main use case, though it does not explicitly name alternatives or say when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
gdelt_list_tv_stationsList GDELT TV StationsARead-onlyInspect
List all television stations available for TV search with their market, network, monitoring start date, and monitoring end date. Stations with an end date within the last 24 hours are flagged as active; stations with earlier end dates are discontinued. Use before querying to verify a station was active during the target time period, or to discover valid station IDs for the stations parameter in other TV tools. Most station monitoring ended October 2024 when the Internet Archive TV feed stopped updating.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
| Name | Required | Description |
|---|---|---|
| error | No | Present when the call failed. Absent on success. |
| stations | No | All TV stations sorted by station ID. |
| totalCount | No | Total number of stations in the list. |
| activeCount | No | Number of stations currently flagged as active. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint annotation, the description reveals meaningful behavior: stations with end dates within the last 24 hours are flagged active, earlier dates are discontinued, and most monitoring ended October 2024 due to the Internet Archive feed. This gives the agent valuable expectations about data freshness and discontinuation that are not inferable from the schema or annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose in the first sentence, then adds the active-flag definition, usage guidance, and historical context in subsequent sentences. Every sentence earns its place and there is no redundant filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With zero parameters and an output schema available, the description needs only to explain what the list contains, how to interpret status, and when to call it. It covers all of that, including the important real-world limitation about October 2024, making the tool fully understandable without additional context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, so the baseline is 4 by rubric. The description correctly focuses on the output rather than parameters, and since there are no inputs to document, no additional parameter semantics are needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
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: 'List all television stations available for TV search,' and details the exact fields returned (market, network, monitoring start/end date). It clearly distinguishes itself from the sibling TV tools by establishing that this is a reference-list endpoint for station discovery, not a search or analysis tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use the tool: 'Use before querying to verify a station was active during the target time period, or to discover valid station IDs for the stations parameter in other TV tools.' It provides clear context but does not name specific alternatives or state when not to use it, stopping 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.
gdelt_search_articlesSearch GDELT ArticlesARead-onlyInspect
Search the last 3 months of global news coverage (65+ languages) using the GDELT DOC API. Returns up to 250 articles with URL, title, source domain, language, country, publication date, and social image URL. Query supports full GDELT syntax: phrases ("bird flu"), boolean OR ((flu OR pandemic)), source country (sourcecountry:china), source language (sourcelang:spanish), domain (domain:who.int), GKG theme (theme:DISEASE_OUTBREAK), tone filter (tone<-5 for negative), proximity (near20:"flu virus"), and repeat (repeat3:"outbreak"). 250 is a hard per-call ceiling and GDELT offers no cursor: when a query fills it, split the run into narrower startDatetime/endDatetime windows — the response hands back the exact windows to use. Note: this API covers only the most recent 3 months — use gdelt_search_tv for historical TV transcripts back to 2009.
| Name | Required | Description | Default |
|---|---|---|---|
| sort | No | Sort order: relevance (default), dateDesc/dateAsc, toneDesc/toneAsc, or hybridRel (GDELT hybrid relevance and recency). | relevance |
| query | Yes | Search query. Supports GDELT operators: phrases ("bird flu"), boolean OR ((flu OR pandemic)), sourcecountry:china, sourcelang:spanish, domain:who.int, theme:DISEASE_OUTBREAK, tone<-5, near20:"flu virus", repeat3:"outbreak". | |
| timespan | No | Time window relative to now, minimum "15min"; other examples: "24h", "7d", "1m". Ignored when startDatetime/endDatetime are set. Maximum is 3 months (the full DOC API window). Defaults to the full 3-month window. | |
| maxRecords | No | Maximum number of articles to return (1–250). 250 is GDELT's hard per-call ceiling, not a page size — there is no cursor past it, so a query that fills 250 must be split into narrower startDatetime/endDatetime windows instead. | |
| endDatetime | No | End of date range in GDELT format YYYYMMDDHHMMSS — exactly 14 digits, no separators (e.g. 20240131235959). Must be supplied together with startDatetime; supplying only one of the two is rejected. | |
| startDatetime | No | Start of date range in GDELT format YYYYMMDDHHMMSS — exactly 14 digits, no separators (e.g. 20240101000000). Must be supplied together with endDatetime; supplying only one of the two is rejected. |
Output Schema
| Name | Required | Description |
|---|---|---|
| error | No | Present when the call failed. Absent on success. |
| notice | No | Disclosure that the maxRecords cap was reached and more articles may exist, naming the route to them — a higher maxRecords below the 250 ceiling, or a narrower date window at it. Absent when the full result set fit under the cap. |
| articles | No | Matching articles sorted per the sort parameter. |
| timespan | No | Echoed timespan parameter when provided. |
| totalCount | No | Number of articles returned in this response. |
| effectiveQuery | No | Echoed query string for use in follow-up calls. |
| continuationWindows | No | The queried window halved, to re-run this query against one pair at a time when maxRecords is at its 250 ceiling. The halves overlap by one second so no article falls through the seam; an article published on that second can come back in both, so de-duplicate by url. Absent unless the ceiling was reached with a window that is both known and wide enough to divide. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already mark this readOnly, and the description adds substantial behavioral detail beyond that: 250 is a hard per-call ceiling with no cursor, the response returns exact split windows when a query fills, timespan is ignored when startDatetime/endDatetime are set, and the API is limited to 3 months. These are exactly the kinds of runtime constraints an agent needs to call the tool correctly.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but every sentence carries unique information: scope, return fields, query syntax, pagination limits, split strategy, and the sibling alternative. It is front-loaded with scope and return value, and the query operator list is organized and purposeful despite being somewhat long.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (6 parameters, rich query syntax, hard pagination limit) and the presence of an output schema, the description is complete: it covers time bounds, result count, operator syntax, sort behavior implications, split strategy, and the key alternative. Nothing essential for selecting or invoking the tool is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Although schema coverage is 100%, the description adds meaning beyond the schema by explaining the semantic implications of maxRecords (hard ceiling, not a page size, no cursor), clarifying the timespan override behavior, and detailing GDELT query operators. It also explains the pair requirement for startDatetime/endDatetime in plain operational terms.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
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: 'Search the last 3 months of global news coverage using the GDELT DOC API.' It clearly states what the tool returns (up to 250 articles with URL, title, source domain, language, country, publication date, and social image URL) and distinguishes itself from gdelt_search_tv by noting that this API covers only the recent 3 months.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit when-to-use guidance and names a concrete alternative: 'use gdelt_search_tv for historical TV transcripts back to 2009.' It also provides actionable direction for handling the 250-article ceiling by splitting queries into narrower startDatetime/endDatetime windows, so an agent knows exactly how to proceed when the limit is hit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
gdelt_search_tvSearch GDELT TV NewsARead-onlyInspect
Search US television news closed captions (2009–October 2024, 150+ stations) for spoken mentions of a query. Returns a bounded, paged per-station time series showing airtime devoted to the topic. Use the stations parameter to select networks (e.g. ["CNN", "FOXNEWS", "MSNBC"]) — the TV API requires at least one station, supplied either there or as a station: selector inside query. TV query also supports in-query operators: station:CNN, network:CBS, market:"National", show:"Anderson Cooper 360", context:"vaccine". Important: most station monitoring ended October 2024 — use gdelt_list_tv_stations to verify active date ranges before querying recent events.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum timeline points returned in this response (1–500). | |
| query | Yes | Search query for TV transcript content. Supports TV operators: station:CNN, network:CBS, market:"National", show:"Anderson Cooper", context:"vaccine". Boolean OR and phrase operators also work. | |
| offset | No | Zero-based point offset into the deterministic date-then-station ordering. Use nextOffset from the preceding response with the same query inputs to retrieve the next page. | |
| dateres | No | Optional GDELT aggregation resolution. Omit to let GDELT choose from the query window; the effective recognized or inferred resolution is returned as dateResolution. | |
| stations | No | Up to 10 station IDs to filter to (e.g. ["CNN", "FOXNEWS", "MSNBC"]). The GDELT TV API requires at least one station — supply it here, or embed a station: selector directly in query. Omitting both is rejected; it does not fall back to all stations. Use gdelt_list_tv_stations to see valid station IDs. | |
| timespan | No | Time window, e.g. "1m", "6m", "1y". Ignored when startDatetime/endDatetime are set. TV data spans 2009–October 2024. | |
| normalize | No | When true (default), values are normalized as % of total airtime, enabling cross-station comparison. When false, returns raw matching 15-second clip counts. | |
| smoothing | No | Smoothing window in timesteps (0 = none). Reduces noise for sporadic topics. | |
| endDatetime | No | End datetime in GDELT format YYYYMMDDHHMMSS — exactly 14 digits, no separators (e.g. 20200131235959). Must pair with startDatetime; supplying only one of the two is rejected. | |
| startDatetime | No | Start datetime in GDELT format YYYYMMDDHHMMSS — exactly 14 digits, no separators (e.g. 20200101000000). Must pair with endDatetime; supplying only one of the two is rejected. |
Output Schema
| Name | Required | Description |
|---|---|---|
| error | No | Present when the call failed. Absent on success. |
| limit | No | Maximum points requested for this page. |
| notice | No | Recovery hint when no TV coverage was found. Absent on successful responses. |
| offset | No | Zero-based offset of this point page. |
| series | No | Station series represented in this point page. |
| timeRange | No | Date range spanned by this returned point page. |
| nextOffset | No | Offset for the next page using the same query inputs. Absent when this is the final page. |
| normalized | No | True when values are normalized coverage percentages. |
| totalCount | No | Number of station series returned. |
| totalPoints | No | Total points available across all matched station series before pagination. |
| dateResolution | No | Temporal resolution of data points. |
| effectiveQuery | No | Echoed query string for use in follow-up calls. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Even with readOnlyHint=true and openWorldHint=true, the description adds meaningful behavioral context: the data source, temporal coverage (2009–October 2024), the station requirement, pagination/boundedness, and the important caveat that most station monitoring ended in October 2024. This goes well beyond the annotations and helps the agent set expectations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core search capability and then moves through station requirements, operator syntax, and the critical October 2024 caveat. It is dense but not bloated; the only mild cost is some repetition of schema-documented details like the station requirement and date range.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given a rich input schema, an output schema, and annotations, the description covers the essential non-obvious facts an agent needs: the need to supply a station, the supported in-query operators, the data's end date, and the recommendation to verify station coverage. Return values are already handled by the output schema, so no further description is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and the schema thoroughly documents all 10 parameters, including the station requirement, operator syntax, date formatting, and normalization behavior. The description largely repeats or re-emphasizes what the schema already states rather than adding new parameter-level meaning, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb ('Search'), a specific resource ('US television news closed captions'), and a clear output ('bounded, paged per-station time series'). It also distinguishes itself from sibling tools by focusing on search over captions and by explicitly invoking gdelt_list_tv_stations, so an agent can tell it apart without opening the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear operational context: the TV API requires at least one station, stations can be supplied via the stations parameter or an in-query operator, and gdelt_list_tv_stations should be used to verify active date ranges before querying recent events. It does not explicitly list exclusions or alternatives such as preferring gdelt_get_tv_clips for clip retrieval, so it falls just short of full 'when-not' guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
4 tool updates
- Changed
gdelt_get_coverage_breakdown2 fields changed- changed
Output schema / properties / dateResolution / descriptionPrevious value: -"Temporal resolution of data points."New value: +"Temporal resolution of data points — 15min, hour, or day." - changed
Output schema / properties / dateResolution / enumPrevious value: -[ - "hour", - "day" -]New value: +[ + "15min", + "hour", + "day" +]
- Changed
gdelt_get_coverage_timeline2 fields changed- changed
Output schema / properties / dateResolution / descriptionPrevious value: -"Temporal resolution of the data points — hour for short windows, day for longer."New value: +"Temporal resolution of the data points — 15min, hour, or day." - changed
Output schema / properties / dateResolution / enumPrevious value: -[ - "hour", - "day" -]New value: +[ + "15min", + "hour", + "day" +]
- Changed
gdelt_search_articles2 fields changed- changed
Input schema / properties / sort / descriptionPrevious value: -"Sort order: relevance (default), date (newest first), social (most socially shared)."New value: +"Sort order: relevance (default), dateDesc/dateAsc, toneDesc/toneAsc, or hybridRel (GDELT hybrid relevance and recency)." - changed
Input schema / properties / sort / enumPrevious value: -[ - "date", - "relevance", - "social" -]New value: +[ + "relevance", + "dateDesc", + "dateAsc", + "toneDesc", + "toneAsc", + "hybridRel" +]
- Changed
gdelt_search_tv17 fields changed- added
Input schema / properties / dateresAdded value: +{ + "description": "Optional GDELT aggregation resolution. Omit to let GDELT choose from the query window; the effective recognized or inferred resolution is returned as dateResolution.", + "enum": [ + "hour", + "day", + "week", + "month", + "year" + ], + "type": "string" +} - added
Input schema / properties / limitAdded value: +{ + "default": 500, + "description": "Maximum timeline points returned in this response (1–500).", + "maximum": 500, + "minimum": 1, + "type": "integer" +} - changed
Input schema / properties / normalize / descriptionPrevious value: -"When true (default), values are normalized as % of total airtime, enabling cross-station comparison. When false, returns raw coverage volume."New value: +"When true (default), values are normalized as % of total airtime, enabling cross-station comparison. When false, returns raw matching 15-second clip counts." - added
Input schema / properties / offsetAdded value: +{ + "default": 0, + "description": "Zero-based point offset into the deterministic date-then-station ordering. Use nextOffset from the preceding response with the same query inputs to retrieve the next page.", + "maximum": 9007199254740991, + "minimum": 0, + "type": "integer" +} - changed
Input schema / properties / stations / descriptionPrevious value: -"Station IDs to filter to (e.g. [\"CNN\", \"FOXNEWS\", \"MSNBC\"]). The GDELT TV API requires at least one station — supply it here, or embed a station: selector directly in query. Omitting both is rejected; it does not fall back to all stations. Use gdelt_list_tv_stations to see valid station IDs."New value: +"Up to 10 station IDs to filter to (e.g. [\"CNN\", \"FOXNEWS\", \"MSNBC\"]). The GDELT TV API requires at least one station — supply it here, or embed a station: selector directly in query. Omitting both is rejected; it does not fall back to all stations. Use gdelt_list_tv_stations to see valid station IDs." - added
Input schema / properties / stations / maxItemsAdded value: +10 - changed
Output schema / anyOfPrevious value: -[ - { - "not": { - "required": [ - "error" - ] - }, - "required": [ - "dateResolution", - "timeRange", - "series", - "normalized", - "effectiveQuery", - "totalCount" - ] - }, - { - "required": [ - "error" - ] - } -]New value: +[ + { + "not": { + "required": [ + "error" + ] + }, + "required": [ + "dateResolution", + "timeRange", + "series", + "normalized", + "totalPoints", + "offset", + "limit", + "effectiveQuery", + "totalCount" + ] + }, + { + "required": [ + "error" + ] + } +] - changed
Output schema / properties / dateResolution / enumPrevious value: -[ - "hour", - "day", - "month" -]New value: +[ + "hour", + "day", + "week", + "month", + "year" +] - changed
Output schema / properties / error / properties / data / properties / reason / descriptionPrevious value: -"Machine-readable failure mode. Declared by this tool: `no_tv_coverage`: No TV coverage found for the query in the specified time range. `invalid_date_range`: Exactly one of startDatetime / endDatetime was supplied. `invalid_query`: GDELT rejected the query — no station was selected, or the query string is malformed. `gdelt_rate_limited`: GDELT rejected the request because its one-request-per-five-seconds limit was reached. `gdelt_unavailable`: GDELT TV API is unreachable or temporarily returned no usable data. Other values are possible when a failure originates below the handler."New value: +"Machine-readable failure mode. Declared by this tool: `no_tv_coverage`: No TV coverage found for the query in the specified time range. `invalid_date_range`: Exactly one of startDatetime / endDatetime was supplied. `offset_out_of_range`: The requested point offset is at or beyond the end of a non-empty timeline. `invalid_query`: GDELT rejected the query — no station was selected, or the query string is malformed. `gdelt_rate_limited`: GDELT rejected the request because its one-request-per-five-seconds limit was reached. `gdelt_unavailable`: GDELT TV API is unreachable or temporarily returned no usable data. Other values are possible when a failure originates below the handler." - changed
Output schema / properties / error / properties / data / properties / reason / examplesPrevious value: -[ - "no_tv_coverage", - "invalid_date_range", - "invalid_query", - "gdelt_rate_limited", - "gdelt_unavailable" -]New value: +[ + "no_tv_coverage", + "invalid_date_range", + "offset_out_of_range", + "invalid_query", + "gdelt_rate_limited", + "gdelt_unavailable" +] - added
Output schema / properties / limitAdded value: +{ + "description": "Maximum points requested for this page.", + "type": "number" +} - added
Output schema / properties / nextOffsetAdded value: +{ + "description": "Offset for the next page using the same query inputs. Absent when this is the final page.", + "type": "number" +} - added
Output schema / properties / offsetAdded value: +{ + "description": "Zero-based offset of this point page.", + "type": "number" +} - changed
Output schema / properties / series / descriptionPrevious value: -"One coverage series per explicitly selected station."New value: +"Station series represented in this point page." - changed
Output schema / properties / series / items / properties / data / items / properties / value / descriptionPrevious value: -"Coverage value (normalized % or raw count)."New value: +"Coverage value (normalized % or raw matching 15-second clip count)." - changed
Output schema / properties / timeRange / descriptionPrevious value: -"Date range spanned by the returned data."New value: +"Date range spanned by this returned point page." - added
Output schema / properties / totalPointsAdded value: +{ + "description": "Total points available across all matched station series before pagination.", + "type": "number" +}
9 tool updates
- Changed
gdelt_get_coverage_breakdown3 fields changed- changed
Input schema / properties / timespan / descriptionPrevious value: -"Time window relative to now, e.g. \"24h\", \"7d\", \"1m\". Ignored when startDatetime/endDatetime are set. Maximum 3 months."New value: +"Time window relative to now, minimum \"15min\"; other examples: \"24h\", \"7d\", \"1m\". Ignored when startDatetime/endDatetime are set. Maximum 3 months." - changed
Output schema / properties / error / properties / data / properties / reason / descriptionPrevious value: -"Machine-readable failure mode. Declared by this tool: `no_breakdown_data`: No breakdown data returned for the query. `unknown_series`: A label passed in the series input matches no series in this breakdown. `invalid_date_range`: Exactly one of startDatetime / endDatetime was supplied. `invalid_query`: GDELT rejected the query string as malformed — bad keyword length, unbalanced parentheses, or an illegal character. `gdelt_unavailable`: GDELT DOC API is unreachable or rate-limited. Other values are possible when a failure originates below the handler."New value: +"Machine-readable failure mode. Declared by this tool: `no_breakdown_data`: No breakdown data returned for the query. `unknown_series`: A label passed in the series input matches no series in this breakdown. `invalid_date_range`: Exactly one of startDatetime / endDatetime was supplied. `invalid_query`: GDELT rejected the query string as malformed — bad keyword length, unbalanced parentheses, or an illegal character. `gdelt_rate_limited`: GDELT rejected the request because its one-request-per-five-seconds limit was reached. `gdelt_unavailable`: GDELT DOC API is unreachable or temporarily returned no usable data. Other values are possible when a failure originates below the handler." - changed
Output schema / properties / error / properties / data / properties / reason / examplesPrevious value: -[ - "no_breakdown_data", - "unknown_series", - "invalid_date_range", - "invalid_query", - "gdelt_unavailable" -]New value: +[ + "no_breakdown_data", + "unknown_series", + "invalid_date_range", + "invalid_query", + "gdelt_rate_limited", + "gdelt_unavailable" +]
- Changed
gdelt_get_coverage_timeline3 fields changed- changed
Input schema / properties / timespan / descriptionPrevious value: -"Time window relative to now, e.g. \"24h\", \"7d\", \"1m\". Ignored when startDatetime/endDatetime are set. Maximum 3 months."New value: +"Time window relative to now, minimum \"15min\"; other examples: \"24h\", \"7d\", \"1m\". Ignored when startDatetime/endDatetime are set. Maximum 3 months." - changed
Output schema / properties / error / properties / data / properties / reason / descriptionPrevious value: -"Machine-readable failure mode. Declared by this tool: `no_timeline_data`: No timeline data returned for the query and time range. `unknown_point`: A date passed in the points input matches no timestep in this timeline. `invalid_date_range`: Exactly one of startDatetime / endDatetime was supplied. `invalid_query`: GDELT rejected the query string as malformed — bad keyword length, unbalanced parentheses, or an illegal character. `gdelt_unavailable`: GDELT DOC API is unreachable or rate-limited. Other values are possible when a failure originates below the handler."New value: +"Machine-readable failure mode. Declared by this tool: `no_timeline_data`: No timeline data returned for the query and time range. `unknown_point`: A date passed in the points input matches no timestep in this timeline. `invalid_date_range`: Exactly one of startDatetime / endDatetime was supplied. `invalid_query`: GDELT rejected the query string as malformed — bad keyword length, unbalanced parentheses, or an illegal character. `gdelt_rate_limited`: GDELT rejected the request because its one-request-per-five-seconds limit was reached. `gdelt_unavailable`: GDELT DOC API is unreachable or temporarily returned no usable data. Other values are possible when a failure originates below the handler." - changed
Output schema / properties / error / properties / data / properties / reason / examplesPrevious value: -[ - "no_timeline_data", - "unknown_point", - "invalid_date_range", - "invalid_query", - "gdelt_unavailable" -]New value: +[ + "no_timeline_data", + "unknown_point", + "invalid_date_range", + "invalid_query", + "gdelt_rate_limited", + "gdelt_unavailable" +]
- Changed
gdelt_get_tone_distribution3 fields changed- changed
Input schema / properties / timespan / descriptionPrevious value: -"Time window relative to now, e.g. \"24h\", \"7d\", \"1m\". Ignored when startDatetime/endDatetime are set. Maximum 3 months."New value: +"Time window relative to now, minimum \"15min\"; other examples: \"24h\", \"7d\", \"1m\". Ignored when startDatetime/endDatetime are set. Maximum 3 months." - changed
Output schema / properties / error / properties / data / properties / reason / descriptionPrevious value: -"Machine-readable failure mode. Declared by this tool: `no_tone_data`: No tone histogram data returned for the query. `invalid_date_range`: Exactly one of startDatetime / endDatetime was supplied. `invalid_query`: GDELT rejected the query string as malformed — bad keyword length, unbalanced parentheses, or an illegal character. `gdelt_unavailable`: GDELT DOC API is unreachable or rate-limited. Other values are possible when a failure originates below the handler."New value: +"Machine-readable failure mode. Declared by this tool: `no_tone_data`: No tone histogram data returned for the query. `invalid_date_range`: Exactly one of startDatetime / endDatetime was supplied. `invalid_query`: GDELT rejected the query string as malformed — bad keyword length, unbalanced parentheses, or an illegal character. `gdelt_rate_limited`: GDELT rejected the request because its one-request-per-five-seconds limit was reached. `gdelt_unavailable`: GDELT DOC API is unreachable or temporarily returned no usable data. Other values are possible when a failure originates below the handler." - changed
Output schema / properties / error / properties / data / properties / reason / examplesPrevious value: -[ - "no_tone_data", - "invalid_date_range", - "invalid_query", - "gdelt_unavailable" -]New value: +[ + "no_tone_data", + "invalid_date_range", + "invalid_query", + "gdelt_rate_limited", + "gdelt_unavailable" +]
- Changed
gdelt_get_tv_clips2 fields changed- changed
Output schema / properties / error / properties / data / properties / reason / descriptionPrevious value: -"Machine-readable failure mode. Declared by this tool: `no_clips`: No TV clips matched the query in the specified time range. `invalid_date_range`: Exactly one of startDatetime / endDatetime was supplied. `invalid_query`: GDELT rejected the query — no station was selected, or the query string is malformed. `gdelt_unavailable`: GDELT TV API is unreachable or rate-limited. Other values are possible when a failure originates below the handler."New value: +"Machine-readable failure mode. Declared by this tool: `no_clips`: No TV clips matched the query in the specified time range. `invalid_date_range`: Exactly one of startDatetime / endDatetime was supplied. `invalid_query`: GDELT rejected the query — no station was selected, or the query string is malformed. `gdelt_rate_limited`: GDELT rejected the request because its one-request-per-five-seconds limit was reached. `gdelt_unavailable`: GDELT TV API is unreachable or temporarily returned no usable data. Other values are possible when a failure originates below the handler." - changed
Output schema / properties / error / properties / data / properties / reason / examplesPrevious value: -[ - "no_clips", - "invalid_date_range", - "invalid_query", - "gdelt_unavailable" -]New value: +[ + "no_clips", + "invalid_date_range", + "invalid_query", + "gdelt_rate_limited", + "gdelt_unavailable" +]
- Changed
gdelt_get_tv_context2 fields changed- changed
Output schema / properties / error / properties / data / properties / reason / descriptionPrevious value: -"Machine-readable failure mode. Declared by this tool: `no_context`: No context words found — no clips matched the query. `invalid_date_range`: Exactly one of startDatetime / endDatetime was supplied. `invalid_query`: GDELT rejected the query — no station was selected, or the query string is malformed. `gdelt_unavailable`: GDELT TV API is unreachable or rate-limited. Other values are possible when a failure originates below the handler."New value: +"Machine-readable failure mode. Declared by this tool: `no_context`: No context words found — no clips matched the query. `invalid_date_range`: Exactly one of startDatetime / endDatetime was supplied. `invalid_query`: GDELT rejected the query — no station was selected, or the query string is malformed. `gdelt_rate_limited`: GDELT rejected the request because its one-request-per-five-seconds limit was reached. `gdelt_unavailable`: GDELT TV API is unreachable or temporarily returned no usable data. Other values are possible when a failure originates below the handler." - changed
Output schema / properties / error / properties / data / properties / reason / examplesPrevious value: -[ - "no_context", - "invalid_date_range", - "invalid_query", - "gdelt_unavailable" -]New value: +[ + "no_context", + "invalid_date_range", + "invalid_query", + "gdelt_rate_limited", + "gdelt_unavailable" +]
- Changed
gdelt_get_tv_trending2 fields changed- changed
Output schema / properties / error / properties / data / properties / reason / descriptionPrevious value: -"Machine-readable failure mode. Declared by this tool: `no_trending`: No trending topics returned — the endpoint returned an empty list. `gdelt_unavailable`: GDELT TV API is unreachable or rate-limited. Other values are possible when a failure originates below the handler."New value: +"Machine-readable failure mode. Declared by this tool: `no_trending`: No trending topics returned — the endpoint returned an empty list. `gdelt_rate_limited`: GDELT rejected the request because its one-request-per-five-seconds limit was reached. `gdelt_unavailable`: GDELT TV API is unreachable or temporarily returned no usable data. Other values are possible when a failure originates below the handler." - changed
Output schema / properties / error / properties / data / properties / reason / examplesPrevious value: -[ - "no_trending", - "gdelt_unavailable" -]New value: +[ + "no_trending", + "gdelt_rate_limited", + "gdelt_unavailable" +]
- Changed
gdelt_list_tv_stations2 fields changed- changed
Output schema / properties / error / properties / data / properties / reason / descriptionPrevious value: -"Machine-readable failure mode. Declared by this tool: `no_stations`: The station list returned empty — API may be temporarily unavailable. `gdelt_unavailable`: GDELT TV API is unreachable or rate-limited. Other values are possible when a failure originates below the handler."New value: +"Machine-readable failure mode. Declared by this tool: `no_stations`: The station list returned empty — API may be temporarily unavailable. `gdelt_rate_limited`: GDELT rejected the request because its one-request-per-five-seconds limit was reached. `gdelt_unavailable`: GDELT TV API is unreachable or temporarily returned no usable data. Other values are possible when a failure originates below the handler." - changed
Output schema / properties / error / properties / data / properties / reason / examplesPrevious value: -[ - "no_stations", - "gdelt_unavailable" -]New value: +[ + "no_stations", + "gdelt_rate_limited", + "gdelt_unavailable" +]
- Changed
gdelt_search_articles3 fields changed- changed
Input schema / properties / timespan / descriptionPrevious value: -"Time window relative to now, e.g. \"24h\", \"7d\", \"1m\". Ignored when startDatetime/endDatetime are set. Maximum is 3 months (the full DOC API window). Defaults to the full 3-month window."New value: +"Time window relative to now, minimum \"15min\"; other examples: \"24h\", \"7d\", \"1m\". Ignored when startDatetime/endDatetime are set. Maximum is 3 months (the full DOC API window). Defaults to the full 3-month window." - changed
Output schema / properties / error / properties / data / properties / reason / descriptionPrevious value: -"Machine-readable failure mode. Declared by this tool: `no_articles`: No articles matched the query within the specified time range. `invalid_date_range`: Exactly one of startDatetime / endDatetime was supplied. `invalid_query`: GDELT rejected the query string as malformed — bad keyword length, unbalanced parentheses, or an illegal character. `gdelt_unavailable`: GDELT DOC API is unreachable or rate-limited. Other values are possible when a failure originates below the handler."New value: +"Machine-readable failure mode. Declared by this tool: `no_articles`: No articles matched the query within the specified time range. `invalid_date_range`: Exactly one of startDatetime / endDatetime was supplied. `invalid_query`: GDELT rejected the query string as malformed — bad keyword length, unbalanced parentheses, or an illegal character. `gdelt_rate_limited`: GDELT rejected the request because its one-request-per-five-seconds limit was reached. `gdelt_unavailable`: GDELT DOC API is unreachable or temporarily returned no usable data. Other values are possible when a failure originates below the handler." - changed
Output schema / properties / error / properties / data / properties / reason / examplesPrevious value: -[ - "no_articles", - "invalid_date_range", - "invalid_query", - "gdelt_unavailable" -]New value: +[ + "no_articles", + "invalid_date_range", + "invalid_query", + "gdelt_rate_limited", + "gdelt_unavailable" +]
- Changed
gdelt_search_tv3 fields changed- changed
Output schema / properties / error / properties / data / properties / reason / descriptionPrevious value: -"Machine-readable failure mode. Declared by this tool: `no_tv_coverage`: No TV coverage found for the query in the specified time range. `invalid_date_range`: Exactly one of startDatetime / endDatetime was supplied. `invalid_query`: GDELT rejected the query — no station was selected, or the query string is malformed. `gdelt_unavailable`: GDELT TV API is unreachable or rate-limited. Other values are possible when a failure originates below the handler."New value: +"Machine-readable failure mode. Declared by this tool: `no_tv_coverage`: No TV coverage found for the query in the specified time range. `invalid_date_range`: Exactly one of startDatetime / endDatetime was supplied. `invalid_query`: GDELT rejected the query — no station was selected, or the query string is malformed. `gdelt_rate_limited`: GDELT rejected the request because its one-request-per-five-seconds limit was reached. `gdelt_unavailable`: GDELT TV API is unreachable or temporarily returned no usable data. Other values are possible when a failure originates below the handler." - changed
Output schema / properties / error / properties / data / properties / reason / examplesPrevious value: -[ - "no_tv_coverage", - "invalid_date_range", - "invalid_query", - "gdelt_unavailable" -]New value: +[ + "no_tv_coverage", + "invalid_date_range", + "invalid_query", + "gdelt_rate_limited", + "gdelt_unavailable" +] - changed
Output schema / properties / series / descriptionPrevious value: -"One series per station or combined national coverage."New value: +"One coverage series per explicitly selected station."
9 tool updates
- Changed
gdelt_get_coverage_breakdown6 fields changed- changed
Input schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema" - added
Input schema / additionalPropertiesAdded value: +false - changed
Output schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema" - added
Output schema / anyOfAdded value: +[ + { + "not": { + "required": [ + "error" + ] + }, + "required": [ + "dateResolution", + "topSeries", + "effectiveQuery", + "breakdownBy", + "totalCount" + ] + }, + { + "required": [ + "error" + ] + } +] - added
Output schema / properties / errorAdded value: +{ + "additionalProperties": {}, + "description": "Present when the call failed. Absent on success.", + "properties": { + "code": { + "description": "JSON-RPC error code for this failure.", + "maximum": 9007199254740991, + "minimum": -9007199254740991, + "type": "integer" + }, + "data": { + "additionalProperties": {}, + "properties": { + "reason": { + "description": "Machine-readable failure mode. Declared by this tool: `no_breakdown_data`: No breakdown data returned for the query. `unknown_series`: A label passed in the series input matches no series in this breakdown. `invalid_date_range`: Exactly one of startDatetime / endDatetime was supplied. `invalid_query`: GDELT rejected the query string as malformed — bad keyword length, unbalanced parentheses, or an illegal character. `gdelt_unavailable`: GDELT DOC API is unreachable or rate-limited. Other values are possible when a failure originates below the handler.", + "examples": [ + "no_breakdown_data", + "unknown_series", + "invalid_date_range", + "invalid_query", + "gdelt_unavailable" + ], + "type": "string" + }, + "recovery": { + "additionalProperties": {}, + "description": "Actionable next step for the caller.", + "properties": { + "hint": { + "type": "string" + } + }, + "required": [ + "hint" + ], + "type": "object" + }, + "retryable": { + "description": "Whether retrying may succeed.", + "type": "boolean" + } + }, + "type": "object" + }, + "message": { + "description": "Human-readable description of what went wrong.", + "type": "string" + } + }, + "required": [ + "code", + "message" + ], + "type": "object" +} - removed
Output schema / requiredRemoved value: -[ - "dateResolution", - "topSeries", - "effectiveQuery", - "breakdownBy", - "totalCount" -]
- Changed
gdelt_get_coverage_timeline6 fields changed- changed
Input schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema" - added
Input schema / additionalPropertiesAdded value: +false - changed
Output schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema" - added
Output schema / anyOfAdded value: +[ + { + "not": { + "required": [ + "error" + ] + }, + "required": [ + "dateResolution", + "series", + "effectiveQuery", + "mode", + "totalCount" + ] + }, + { + "required": [ + "error" + ] + } +] - added
Output schema / properties / errorAdded value: +{ + "additionalProperties": {}, + "description": "Present when the call failed. Absent on success.", + "properties": { + "code": { + "description": "JSON-RPC error code for this failure.", + "maximum": 9007199254740991, + "minimum": -9007199254740991, + "type": "integer" + }, + "data": { + "additionalProperties": {}, + "properties": { + "reason": { + "description": "Machine-readable failure mode. Declared by this tool: `no_timeline_data`: No timeline data returned for the query and time range. `unknown_point`: A date passed in the points input matches no timestep in this timeline. `invalid_date_range`: Exactly one of startDatetime / endDatetime was supplied. `invalid_query`: GDELT rejected the query string as malformed — bad keyword length, unbalanced parentheses, or an illegal character. `gdelt_unavailable`: GDELT DOC API is unreachable or rate-limited. Other values are possible when a failure originates below the handler.", + "examples": [ + "no_timeline_data", + "unknown_point", + "invalid_date_range", + "invalid_query", + "gdelt_unavailable" + ], + "type": "string" + }, + "recovery": { + "additionalProperties": {}, + "description": "Actionable next step for the caller.", + "properties": { + "hint": { + "type": "string" + } + }, + "required": [ + "hint" + ], + "type": "object" + }, + "retryable": { + "description": "Whether retrying may succeed.", + "type": "boolean" + } + }, + "type": "object" + }, + "message": { + "description": "Human-readable description of what went wrong.", + "type": "string" + } + }, + "required": [ + "code", + "message" + ], + "type": "object" +} - removed
Output schema / requiredRemoved value: -[ - "dateResolution", - "series", - "effectiveQuery", - "mode", - "totalCount" -]
- Changed
gdelt_get_tone_distribution6 fields changed- changed
Input schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema" - added
Input schema / additionalPropertiesAdded value: +false - changed
Output schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema" - added
Output schema / anyOfAdded value: +[ + { + "not": { + "required": [ + "error" + ] + }, + "required": [ + "histogram", + "summary", + "effectiveQuery", + "totalCount" + ] + }, + { + "required": [ + "error" + ] + } +] - added
Output schema / properties / errorAdded value: +{ + "additionalProperties": {}, + "description": "Present when the call failed. Absent on success.", + "properties": { + "code": { + "description": "JSON-RPC error code for this failure.", + "maximum": 9007199254740991, + "minimum": -9007199254740991, + "type": "integer" + }, + "data": { + "additionalProperties": {}, + "properties": { + "reason": { + "description": "Machine-readable failure mode. Declared by this tool: `no_tone_data`: No tone histogram data returned for the query. `invalid_date_range`: Exactly one of startDatetime / endDatetime was supplied. `invalid_query`: GDELT rejected the query string as malformed — bad keyword length, unbalanced parentheses, or an illegal character. `gdelt_unavailable`: GDELT DOC API is unreachable or rate-limited. Other values are possible when a failure originates below the handler.", + "examples": [ + "no_tone_data", + "invalid_date_range", + "invalid_query", + "gdelt_unavailable" + ], + "type": "string" + }, + "recovery": { + "additionalProperties": {}, + "description": "Actionable next step for the caller.", + "properties": { + "hint": { + "type": "string" + } + }, + "required": [ + "hint" + ], + "type": "object" + }, + "retryable": { + "description": "Whether retrying may succeed.", + "type": "boolean" + } + }, + "type": "object" + }, + "message": { + "description": "Human-readable description of what went wrong.", + "type": "string" + } + }, + "required": [ + "code", + "message" + ], + "type": "object" +} - removed
Output schema / requiredRemoved value: -[ - "histogram", - "summary", - "effectiveQuery", - "totalCount" -]
- Changed
gdelt_get_tv_clips6 fields changed- changed
Input schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema" - added
Input schema / additionalPropertiesAdded value: +false - changed
Output schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema" - added
Output schema / anyOfAdded value: +[ + { + "not": { + "required": [ + "error" + ] + }, + "required": [ + "clips", + "effectiveQuery", + "totalCount" + ] + }, + { + "required": [ + "error" + ] + } +] - added
Output schema / properties / errorAdded value: +{ + "additionalProperties": {}, + "description": "Present when the call failed. Absent on success.", + "properties": { + "code": { + "description": "JSON-RPC error code for this failure.", + "maximum": 9007199254740991, + "minimum": -9007199254740991, + "type": "integer" + }, + "data": { + "additionalProperties": {}, + "properties": { + "reason": { + "description": "Machine-readable failure mode. Declared by this tool: `no_clips`: No TV clips matched the query in the specified time range. `invalid_date_range`: Exactly one of startDatetime / endDatetime was supplied. `invalid_query`: GDELT rejected the query — no station was selected, or the query string is malformed. `gdelt_unavailable`: GDELT TV API is unreachable or rate-limited. Other values are possible when a failure originates below the handler.", + "examples": [ + "no_clips", + "invalid_date_range", + "invalid_query", + "gdelt_unavailable" + ], + "type": "string" + }, + "recovery": { + "additionalProperties": {}, + "description": "Actionable next step for the caller.", + "properties": { + "hint": { + "type": "string" + } + }, + "required": [ + "hint" + ], + "type": "object" + }, + "retryable": { + "description": "Whether retrying may succeed.", + "type": "boolean" + } + }, + "type": "object" + }, + "message": { + "description": "Human-readable description of what went wrong.", + "type": "string" + } + }, + "required": [ + "code", + "message" + ], + "type": "object" +} - removed
Output schema / requiredRemoved value: -[ - "clips", - "effectiveQuery", - "totalCount" -]
- Changed
gdelt_get_tv_context6 fields changed- changed
Input schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema" - added
Input schema / additionalPropertiesAdded value: +false - changed
Output schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema" - added
Output schema / anyOfAdded value: +[ + { + "not": { + "required": [ + "error" + ] + }, + "required": [ + "words", + "effectiveQuery" + ] + }, + { + "required": [ + "error" + ] + } +] - added
Output schema / properties / errorAdded value: +{ + "additionalProperties": {}, + "description": "Present when the call failed. Absent on success.", + "properties": { + "code": { + "description": "JSON-RPC error code for this failure.", + "maximum": 9007199254740991, + "minimum": -9007199254740991, + "type": "integer" + }, + "data": { + "additionalProperties": {}, + "properties": { + "reason": { + "description": "Machine-readable failure mode. Declared by this tool: `no_context`: No context words found — no clips matched the query. `invalid_date_range`: Exactly one of startDatetime / endDatetime was supplied. `invalid_query`: GDELT rejected the query — no station was selected, or the query string is malformed. `gdelt_unavailable`: GDELT TV API is unreachable or rate-limited. Other values are possible when a failure originates below the handler.", + "examples": [ + "no_context", + "invalid_date_range", + "invalid_query", + "gdelt_unavailable" + ], + "type": "string" + }, + "recovery": { + "additionalProperties": {}, + "description": "Actionable next step for the caller.", + "properties": { + "hint": { + "type": "string" + } + }, + "required": [ + "hint" + ], + "type": "object" + }, + "retryable": { + "description": "Whether retrying may succeed.", + "type": "boolean" + } + }, + "type": "object" + }, + "message": { + "description": "Human-readable description of what went wrong.", + "type": "string" + } + }, + "required": [ + "code", + "message" + ], + "type": "object" +} - removed
Output schema / requiredRemoved value: -[ - "words", - "effectiveQuery" -]
- Changed
gdelt_get_tv_trending6 fields changed- changed
Input schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema" - added
Input schema / additionalPropertiesAdded value: +false - changed
Output schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema" - added
Output schema / anyOfAdded value: +[ + { + "not": { + "required": [ + "error" + ] + }, + "required": [ + "topics", + "totalCount" + ] + }, + { + "required": [ + "error" + ] + } +] - added
Output schema / properties / errorAdded value: +{ + "additionalProperties": {}, + "description": "Present when the call failed. Absent on success.", + "properties": { + "code": { + "description": "JSON-RPC error code for this failure.", + "maximum": 9007199254740991, + "minimum": -9007199254740991, + "type": "integer" + }, + "data": { + "additionalProperties": {}, + "properties": { + "reason": { + "description": "Machine-readable failure mode. Declared by this tool: `no_trending`: No trending topics returned — the endpoint returned an empty list. `gdelt_unavailable`: GDELT TV API is unreachable or rate-limited. Other values are possible when a failure originates below the handler.", + "examples": [ + "no_trending", + "gdelt_unavailable" + ], + "type": "string" + }, + "recovery": { + "additionalProperties": {}, + "description": "Actionable next step for the caller.", + "properties": { + "hint": { + "type": "string" + } + }, + "required": [ + "hint" + ], + "type": "object" + }, + "retryable": { + "description": "Whether retrying may succeed.", + "type": "boolean" + } + }, + "type": "object" + }, + "message": { + "description": "Human-readable description of what went wrong.", + "type": "string" + } + }, + "required": [ + "code", + "message" + ], + "type": "object" +} - removed
Output schema / requiredRemoved value: -[ - "topics", - "totalCount" -]
- Changed
gdelt_list_tv_stations6 fields changed- changed
Input schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema" - added
Input schema / additionalPropertiesAdded value: +false - changed
Output schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema" - added
Output schema / anyOfAdded value: +[ + { + "not": { + "required": [ + "error" + ] + }, + "required": [ + "stations", + "activeCount", + "totalCount" + ] + }, + { + "required": [ + "error" + ] + } +] - added
Output schema / properties / errorAdded value: +{ + "additionalProperties": {}, + "description": "Present when the call failed. Absent on success.", + "properties": { + "code": { + "description": "JSON-RPC error code for this failure.", + "maximum": 9007199254740991, + "minimum": -9007199254740991, + "type": "integer" + }, + "data": { + "additionalProperties": {}, + "properties": { + "reason": { + "description": "Machine-readable failure mode. Declared by this tool: `no_stations`: The station list returned empty — API may be temporarily unavailable. `gdelt_unavailable`: GDELT TV API is unreachable or rate-limited. Other values are possible when a failure originates below the handler.", + "examples": [ + "no_stations", + "gdelt_unavailable" + ], + "type": "string" + }, + "recovery": { + "additionalProperties": {}, + "description": "Actionable next step for the caller.", + "properties": { + "hint": { + "type": "string" + } + }, + "required": [ + "hint" + ], + "type": "object" + }, + "retryable": { + "description": "Whether retrying may succeed.", + "type": "boolean" + } + }, + "type": "object" + }, + "message": { + "description": "Human-readable description of what went wrong.", + "type": "string" + } + }, + "required": [ + "code", + "message" + ], + "type": "object" +} - removed
Output schema / requiredRemoved value: -[ - "stations", - "activeCount", - "totalCount" -]
- Changed
gdelt_search_articles6 fields changed- changed
Input schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema" - added
Input schema / additionalPropertiesAdded value: +false - changed
Output schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema" - added
Output schema / anyOfAdded value: +[ + { + "not": { + "required": [ + "error" + ] + }, + "required": [ + "articles", + "effectiveQuery", + "totalCount" + ] + }, + { + "required": [ + "error" + ] + } +] - added
Output schema / properties / errorAdded value: +{ + "additionalProperties": {}, + "description": "Present when the call failed. Absent on success.", + "properties": { + "code": { + "description": "JSON-RPC error code for this failure.", + "maximum": 9007199254740991, + "minimum": -9007199254740991, + "type": "integer" + }, + "data": { + "additionalProperties": {}, + "properties": { + "reason": { + "description": "Machine-readable failure mode. Declared by this tool: `no_articles`: No articles matched the query within the specified time range. `invalid_date_range`: Exactly one of startDatetime / endDatetime was supplied. `invalid_query`: GDELT rejected the query string as malformed — bad keyword length, unbalanced parentheses, or an illegal character. `gdelt_unavailable`: GDELT DOC API is unreachable or rate-limited. Other values are possible when a failure originates below the handler.", + "examples": [ + "no_articles", + "invalid_date_range", + "invalid_query", + "gdelt_unavailable" + ], + "type": "string" + }, + "recovery": { + "additionalProperties": {}, + "description": "Actionable next step for the caller.", + "properties": { + "hint": { + "type": "string" + } + }, + "required": [ + "hint" + ], + "type": "object" + }, + "retryable": { + "description": "Whether retrying may succeed.", + "type": "boolean" + } + }, + "type": "object" + }, + "message": { + "description": "Human-readable description of what went wrong.", + "type": "string" + } + }, + "required": [ + "code", + "message" + ], + "type": "object" +} - removed
Output schema / requiredRemoved value: -[ - "articles", - "effectiveQuery", - "totalCount" -]
- Changed
gdelt_search_tv6 fields changed- changed
Input schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema" - added
Input schema / additionalPropertiesAdded value: +false - changed
Output schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema" - added
Output schema / anyOfAdded value: +[ + { + "not": { + "required": [ + "error" + ] + }, + "required": [ + "dateResolution", + "timeRange", + "series", + "normalized", + "effectiveQuery", + "totalCount" + ] + }, + { + "required": [ + "error" + ] + } +] - added
Output schema / properties / errorAdded value: +{ + "additionalProperties": {}, + "description": "Present when the call failed. Absent on success.", + "properties": { + "code": { + "description": "JSON-RPC error code for this failure.", + "maximum": 9007199254740991, + "minimum": -9007199254740991, + "type": "integer" + }, + "data": { + "additionalProperties": {}, + "properties": { + "reason": { + "description": "Machine-readable failure mode. Declared by this tool: `no_tv_coverage`: No TV coverage found for the query in the specified time range. `invalid_date_range`: Exactly one of startDatetime / endDatetime was supplied. `invalid_query`: GDELT rejected the query — no station was selected, or the query string is malformed. `gdelt_unavailable`: GDELT TV API is unreachable or rate-limited. Other values are possible when a failure originates below the handler.", + "examples": [ + "no_tv_coverage", + "invalid_date_range", + "invalid_query", + "gdelt_unavailable" + ], + "type": "string" + }, + "recovery": { + "additionalProperties": {}, + "description": "Actionable next step for the caller.", + "properties": { + "hint": { + "type": "string" + } + }, + "required": [ + "hint" + ], + "type": "object" + }, + "retryable": { + "description": "Whether retrying may succeed.", + "type": "boolean" + } + }, + "type": "object" + }, + "message": { + "description": "Human-readable description of what went wrong.", + "type": "string" + } + }, + "required": [ + "code", + "message" + ], + "type": "object" +} - removed
Output schema / requiredRemoved value: -[ - "dateResolution", - "timeRange", - "series", - "normalized", - "effectiveQuery", - "totalCount" -]
4 tool updates
- Changed
gdelt_get_coverage_breakdown3 fields changed- added
Input schema / properties / seriesAdded value: +{ + "description": "Exact 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.", + "items": { + "type": "string" + }, + "type": "array" +} - added
Output schema / properties / otherSeriesLabelsAdded value: +{ + "description": "Label 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.", + "items": { + "type": "string" + }, + "type": "array" +} - added
Output schema / properties / selectedSeriesAdded value: +{ + "description": "Complete, untruncated time series for each label requested via the series input, in the order requested. Omitted when series was not supplied.", + "items": { + "additionalProperties": false, + "description": "A single language or country coverage series.", + "properties": { + "data": { + "description": "Time-ordered data points for this series.", + "items": { + "additionalProperties": false, + "description": "A single data point for this series.", + "properties": { + "date": { + "description": "Timestep in ISO 8601 format.", + "type": "string" + }, + "value": { + "description": "Normalized coverage volume at this timestep — the topic's share of this source's media output, not an absolute article count.", + "type": "number" + } + }, + "required": [ + "date", + "value" + ], + "type": "object" + }, + "type": "array" + }, + "label": { + "description": "Series label (language name or country name).", + "type": "string" + } + }, + "required": [ + "label", + "data" + ], + "type": "object" + }, + "type": "array" +}
- Changed
gdelt_get_coverage_timeline2 fields changed- added
Input schema / properties / pointsAdded value: +{ + "description": "Timestep 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.", + "items": { + "type": "string" + }, + "type": "array" +} - added
Output schema / properties / expandedPointsAdded value: +{ + "description": "Timestep 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.", + "items": { + "type": "string" + }, + "type": "array" +}
- Changed
gdelt_get_tv_clips3 fields changed- changed
Input schema / properties / maxRecords / descriptionPrevious value: -"Maximum number of clips to return (1–3000)."New value: +"Maximum number of clips to return (1–3000). 3000 is GDELT's hard per-call ceiling, not a page size — there is no cursor past it, so a query that fills 3000 must be split into narrower startDatetime/endDatetime windows instead." - added
Output schema / properties / continuationWindowsAdded value: +{ + "description": "The queried window halved, to re-run this query against one pair at a time when maxRecords is at its 3000 ceiling. The halves overlap by one second so no clip falls through the seam; a clip aired on that second can come back in both, so de-duplicate by archiveUrl. Absent unless the ceiling was reached with a window that is both known and wide enough to divide.", + "items": { + "additionalProperties": false, + "description": "One window to re-query with the same query string.", + "properties": { + "endDatetime": { + "description": "End of this window in GDELT format YYYYMMDDHHMMSS.", + "type": "string" + }, + "startDatetime": { + "description": "Start of this window in GDELT format YYYYMMDDHHMMSS.", + "type": "string" + } + }, + "required": [ + "startDatetime", + "endDatetime" + ], + "type": "object" + }, + "type": "array" +} - changed
Output schema / properties / notice / descriptionPrevious value: -"Recovery hint when no clips matched. Absent on successful responses."New value: +"Disclosure that the maxRecords cap was reached and more clips may exist, naming the route to them — a higher maxRecords below the 3000 ceiling, or a narrower date window at it. Absent when the full result set fit under the cap."
- Changed
gdelt_search_articles3 fields changed- changed
Input schema / properties / maxRecords / descriptionPrevious value: -"Maximum number of articles to return (1–250)."New value: +"Maximum number of articles to return (1–250). 250 is GDELT's hard per-call ceiling, not a page size — there is no cursor past it, so a query that fills 250 must be split into narrower startDatetime/endDatetime windows instead." - added
Output schema / properties / continuationWindowsAdded value: +{ + "description": "The queried window halved, to re-run this query against one pair at a time when maxRecords is at its 250 ceiling. The halves overlap by one second so no article falls through the seam; an article published on that second can come back in both, so de-duplicate by url. Absent unless the ceiling was reached with a window that is both known and wide enough to divide.", + "items": { + "additionalProperties": false, + "description": "One window to re-query with the same query string.", + "properties": { + "endDatetime": { + "description": "End of this window in GDELT format YYYYMMDDHHMMSS.", + "type": "string" + }, + "startDatetime": { + "description": "Start of this window in GDELT format YYYYMMDDHHMMSS.", + "type": "string" + } + }, + "required": [ + "startDatetime", + "endDatetime" + ], + "type": "object" + }, + "type": "array" +} - changed
Output schema / properties / notice / descriptionPrevious value: -"Recovery hint when no articles matched — echoes filters and suggests how to broaden. Absent on successful responses."New value: +"Disclosure that the maxRecords cap was reached and more articles may exist, naming the route to them — a higher maxRecords below the 250 ceiling, or a narrower date window at it. Absent when the full result set fit under the cap."
1 tool update
- Changed
gdelt_get_coverage_breakdown2 fields changed- changed
Output schema / properties / otherAggregated / items / properties / value / descriptionPrevious value: -"Aggregated coverage volume for all remaining series."New value: +"Aggregated normalized coverage volume for all remaining series — a share of media output, not an absolute article count." - changed
Output schema / properties / topSeries / items / properties / data / items / properties / value / descriptionPrevious value: -"Normalized coverage volume at this timestep."New value: +"Normalized coverage volume at this timestep — the topic's share of this source's media output, not an absolute article count."
7 tool updates
- Changed
gdelt_get_coverage_breakdown4 fields changed- changed
Input schema / properties / endDatetime / descriptionPrevious value: -"End datetime in GDELT format YYYYMMDDHHMMSS. Must pair with startDatetime."New value: +"End 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." - added
Input schema / properties / endDatetime / patternAdded value: +"^\\d{14}$" - changed
Input schema / properties / startDatetime / descriptionPrevious value: -"Start datetime in GDELT format YYYYMMDDHHMMSS. Must pair with endDatetime."New value: +"Start 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." - added
Input schema / properties / startDatetime / patternAdded value: +"^\\d{14}$"
- Changed
gdelt_get_coverage_timeline4 fields changed- changed
Input schema / properties / endDatetime / descriptionPrevious value: -"End datetime in GDELT format YYYYMMDDHHMMSS. Must pair with startDatetime."New value: +"End 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." - added
Input schema / properties / endDatetime / patternAdded value: +"^\\d{14}$" - changed
Input schema / properties / startDatetime / descriptionPrevious value: -"Start datetime in GDELT format YYYYMMDDHHMMSS. Must pair with endDatetime."New value: +"Start 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." - added
Input schema / properties / startDatetime / patternAdded value: +"^\\d{14}$"
- Changed
gdelt_get_tone_distribution4 fields changed- changed
Input schema / properties / endDatetime / descriptionPrevious value: -"End datetime in GDELT format YYYYMMDDHHMMSS. Must pair with startDatetime."New value: +"End 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." - added
Input schema / properties / endDatetime / patternAdded value: +"^\\d{14}$" - changed
Input schema / properties / startDatetime / descriptionPrevious value: -"Start datetime in GDELT format YYYYMMDDHHMMSS. Must pair with endDatetime."New value: +"Start 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." - added
Input schema / properties / startDatetime / patternAdded value: +"^\\d{14}$"
- Changed
gdelt_get_tv_clips5 fields changed- changed
Input schema / properties / endDatetime / descriptionPrevious value: -"End datetime in GDELT format YYYYMMDDHHMMSS. Must pair with startDatetime."New value: +"End datetime in GDELT format YYYYMMDDHHMMSS — exactly 14 digits, no separators (e.g. 20200131235959). Must pair with startDatetime; supplying only one of the two is rejected." - added
Input schema / properties / endDatetime / patternAdded value: +"^\\d{14}$" - changed
Input schema / properties / startDatetime / descriptionPrevious value: -"Start datetime in GDELT format YYYYMMDDHHMMSS. Must pair with endDatetime."New value: +"Start datetime in GDELT format YYYYMMDDHHMMSS — exactly 14 digits, no separators (e.g. 20200101000000). Must pair with endDatetime; supplying only one of the two is rejected." - added
Input schema / properties / startDatetime / patternAdded value: +"^\\d{14}$" - changed
Input schema / properties / stations / descriptionPrevious value: -"Station IDs to filter to (e.g. [\"CNN\", \"FOXNEWS\"]). Omit for all stations. Use gdelt_list_tv_stations to see valid IDs."New value: +"Station IDs to filter to (e.g. [\"CNN\", \"FOXNEWS\"]). The GDELT TV API requires at least one station — supply it here, or embed a station: selector directly in query. Omitting both is rejected; it does not fall back to all stations. Use gdelt_list_tv_stations to see valid IDs."
- Changed
gdelt_get_tv_context5 fields changed- changed
Input schema / properties / endDatetime / descriptionPrevious value: -"End datetime in GDELT format YYYYMMDDHHMMSS. Must pair with startDatetime."New value: +"End datetime in GDELT format YYYYMMDDHHMMSS — exactly 14 digits, no separators (e.g. 20200131235959). Must pair with startDatetime; supplying only one of the two is rejected." - added
Input schema / properties / endDatetime / patternAdded value: +"^\\d{14}$" - changed
Input schema / properties / startDatetime / descriptionPrevious value: -"Start datetime in GDELT format YYYYMMDDHHMMSS. Must pair with endDatetime. TV data spans 2009–October 2024."New value: +"Start datetime in GDELT format YYYYMMDDHHMMSS — exactly 14 digits, no separators (e.g. 20200101000000). Must pair with endDatetime; supplying only one of the two is rejected. TV data spans 2009–October 2024." - added
Input schema / properties / startDatetime / patternAdded value: +"^\\d{14}$" - changed
Input schema / properties / stations / descriptionPrevious value: -"Station IDs to filter to. Omit for all stations. Use gdelt_list_tv_stations to see valid IDs."New value: +"Station IDs to filter to (e.g. [\"CNN\", \"FOXNEWS\"]). The GDELT TV API requires at least one station — supply it here, or embed a station: selector directly in query. Omitting both is rejected; it does not fall back to all stations. Use gdelt_list_tv_stations to see valid IDs."
- Changed
gdelt_search_articles4 fields changed- changed
Input schema / properties / endDatetime / descriptionPrevious value: -"End of date range in GDELT format YYYYMMDDHHMMSS (e.g. 20240131235959). Must be used together with startDatetime."New value: +"End of date range in GDELT format YYYYMMDDHHMMSS — exactly 14 digits, no separators (e.g. 20240131235959). Must be supplied together with startDatetime; supplying only one of the two is rejected." - added
Input schema / properties / endDatetime / patternAdded value: +"^\\d{14}$" - changed
Input schema / properties / startDatetime / descriptionPrevious value: -"Start of date range in GDELT format YYYYMMDDHHMMSS (e.g. 20240101000000). Must be used together with endDatetime."New value: +"Start of date range in GDELT format YYYYMMDDHHMMSS — exactly 14 digits, no separators (e.g. 20240101000000). Must be supplied together with endDatetime; supplying only one of the two is rejected." - added
Input schema / properties / startDatetime / patternAdded value: +"^\\d{14}$"
- Changed
gdelt_search_tv5 fields changed- changed
Input schema / properties / endDatetime / descriptionPrevious value: -"End datetime in GDELT format YYYYMMDDHHMMSS. Must pair with startDatetime."New value: +"End datetime in GDELT format YYYYMMDDHHMMSS — exactly 14 digits, no separators (e.g. 20200131235959). Must pair with startDatetime; supplying only one of the two is rejected." - added
Input schema / properties / endDatetime / patternAdded value: +"^\\d{14}$" - changed
Input schema / properties / startDatetime / descriptionPrevious value: -"Start datetime in GDELT format YYYYMMDDHHMMSS. Must pair with endDatetime."New value: +"Start datetime in GDELT format YYYYMMDDHHMMSS — exactly 14 digits, no separators (e.g. 20200101000000). Must pair with endDatetime; supplying only one of the two is rejected." - added
Input schema / properties / startDatetime / patternAdded value: +"^\\d{14}$" - changed
Input schema / properties / stations / descriptionPrevious value: -"Station IDs to filter to (e.g. [\"CNN\", \"FOXNEWS\", \"MSNBC\"]). Omit to get coverage across all available stations. Use gdelt_list_tv_stations to see valid station IDs."New value: +"Station IDs to filter to (e.g. [\"CNN\", \"FOXNEWS\", \"MSNBC\"]). The GDELT TV API requires at least one station — supply it here, or embed a station: selector directly in query. Omitting both is rejected; it does not fall back to all stations. Use gdelt_list_tv_stations to see valid station IDs."
4 tool updates
- Changed
gdelt_get_coverage_breakdown2 fields changed- added
Output schema / properties / endDatetimeAdded value: +{ + "description": "Echoed end datetime when provided (YYYYMMDDHHMMSS).", + "type": "string" +} - added
Output schema / properties / startDatetimeAdded value: +{ + "description": "Echoed start datetime when provided (YYYYMMDDHHMMSS).", + "type": "string" +}
- Changed
gdelt_get_coverage_timeline2 fields changed- added
Output schema / properties / endDatetimeAdded value: +{ + "description": "Echoed end datetime when provided (YYYYMMDDHHMMSS).", + "type": "string" +} - added
Output schema / properties / startDatetimeAdded value: +{ + "description": "Echoed start datetime when provided (YYYYMMDDHHMMSS).", + "type": "string" +}
- Changed
gdelt_get_tone_distribution2 fields changed- added
Output schema / properties / endDatetimeAdded value: +{ + "description": "Echoed end datetime when provided (YYYYMMDDHHMMSS).", + "type": "string" +} - added
Output schema / properties / startDatetimeAdded value: +{ + "description": "Echoed start datetime when provided (YYYYMMDDHHMMSS).", + "type": "string" +}
- Changed
gdelt_get_tv_context3 fields changed- added
Input schema / properties / endDatetimeAdded value: +{ + "description": "End datetime in GDELT format YYYYMMDDHHMMSS. Must pair with startDatetime.", + "type": "string" +} - added
Input schema / properties / startDatetimeAdded value: +{ + "description": "Start datetime in GDELT format YYYYMMDDHHMMSS. Must pair with endDatetime. TV data spans 2009–October 2024.", + "type": "string" +} - changed
Input schema / properties / timespan / descriptionPrevious value: -"Time window, e.g. \"1m\", \"6m\". TV data spans 2009–October 2024."New value: +"Time window, e.g. \"1m\", \"6m\". Ignored when startDatetime/endDatetime are set. TV data spans 2009–October 2024."
1 tool update
- Changed
gdelt_get_tv_context2 fields changed- changed
Output schema / properties / totalCount / descriptionPrevious value: -"Number of matching clips from which co-occurrences were computed."New value: +"Number of clips from which co-occurrences were computed. Absent when the upstream API does not return a clip count." - changed
Output schema / requiredPrevious value: -[ - "words", - "effectiveQuery", - "totalCount" -]New value: +[ + "words", + "effectiveQuery" +]
8 tool updates
- Changed
gdelt_get_coverage_breakdown7 fields changed- changed
Output schema / properties / breakdownBy / descriptionPrevious value: -"Breakdown dimension used."New value: +"Breakdown dimension used for this response." - added
Output schema / properties / effectiveQueryAdded value: +{ + "description": "Echoed query string for use in follow-up calls.", + "type": "string" +} - changed
Output schema / properties / notice / descriptionPrevious value: -"Recovery hint when no data was returned. Absent on successful responses."New value: +"Recovery hint when no breakdown data was returned. Absent on successful responses." - removed
Output schema / properties / queryRemoved value: -{ - "description": "Echoed query string.", - "type": "string" -} - removed
Output schema / properties / seriesCountRemoved value: -{ - "description": "Total number of series before truncation to top 10.", - "type": "number" -} - added
Output schema / properties / totalCountAdded value: +{ + "description": "Total number of series returned before truncation to top 10.", + "type": "number" +} - changed
Output schema / requiredPrevious value: -[ - "query", - "breakdownBy", - "dateResolution", - "topSeries", - "seriesCount" -]New value: +[ + "dateResolution", + "topSeries", + "effectiveQuery", + "breakdownBy", + "totalCount" +]
- Changed
gdelt_get_coverage_timeline6 fields changed- added
Output schema / properties / effectiveQueryAdded value: +{ + "description": "Echoed query string for use in follow-up calls.", + "type": "string" +} - changed
Output schema / properties / mode / descriptionPrevious value: -"Timeline mode used."New value: +"Timeline mode used for this response." - changed
Output schema / properties / notice / descriptionPrevious value: -"Recovery hint when no data was returned. Absent on successful responses."New value: +"Recovery hint when no timeline data was returned. Absent on successful responses." - removed
Output schema / properties / queryRemoved value: -{ - "description": "Echoed query string.", - "type": "string" -} - added
Output schema / properties / totalCountAdded value: +{ + "description": "Total number of data points across all series.", + "type": "number" +} - changed
Output schema / requiredPrevious value: -[ - "query", - "mode", - "dateResolution", - "series" -]New value: +[ + "dateResolution", + "series", + "effectiveQuery", + "mode", + "totalCount" +]
- Changed
gdelt_get_tone_distribution5 fields changed- added
Output schema / properties / effectiveQueryAdded value: +{ + "description": "Echoed query string for use in follow-up calls.", + "type": "string" +} - changed
Output schema / properties / notice / descriptionPrevious value: -"Recovery hint when no data was returned. Absent on successful responses."New value: +"Recovery hint when no tone data was returned. Absent on successful responses." - removed
Output schema / properties / queryRemoved value: -{ - "description": "Echoed query string.", - "type": "string" -} - added
Output schema / properties / totalCountAdded value: +{ + "description": "Total number of articles across all histogram bins.", + "type": "number" +} - changed
Output schema / requiredPrevious value: -[ - "query", - "histogram", - "summary" -]New value: +[ + "histogram", + "summary", + "effectiveQuery", + "totalCount" +]
- Changed
gdelt_get_tv_clips5 fields changed- added
Output schema / properties / effectiveQueryAdded value: +{ + "description": "Echoed query string for use in follow-up calls.", + "type": "string" +} - removed
Output schema / properties / queryRemoved value: -{ - "description": "Echoed query string.", - "type": "string" -} - added
Output schema / properties / totalCountAdded value: +{ + "description": "Number of clips returned.", + "type": "number" +} - removed
Output schema / properties / totalReturnedRemoved value: -{ - "description": "Number of clips returned.", - "type": "number" -} - changed
Output schema / requiredPrevious value: -[ - "query", - "clips", - "totalReturned" -]New value: +[ + "clips", + "effectiveQuery", + "totalCount" +]
- Changed
gdelt_get_tv_context5 fields changed- removed
Output schema / properties / clipsAnalyzedRemoved value: -{ - "description": "Number of matching clips from which co-occurrences were computed.", - "type": "number" -} - added
Output schema / properties / effectiveQueryAdded value: +{ + "description": "Echoed query string for use in follow-up calls.", + "type": "string" +} - removed
Output schema / properties / queryRemoved value: -{ - "description": "Echoed query string.", - "type": "string" -} - added
Output schema / properties / totalCountAdded value: +{ + "description": "Number of matching clips from which co-occurrences were computed.", + "type": "number" +} - changed
Output schema / requiredPrevious value: -[ - "query", - "words", - "clipsAnalyzed" -]New value: +[ + "words", + "effectiveQuery", + "totalCount" +]
- Changed
gdelt_get_tv_trending2 fields changed- changed
Output schema / properties / notice / descriptionPrevious value: -"Recovery hint when no topics were returned. Absent on successful responses."New value: +"Recovery hint when no trending topics were returned. Absent on successful responses." - changed
Output schema / properties / totalCount / descriptionPrevious value: -"Number of trending topics returned."New value: +"Total number of trending topics returned."
- Changed
gdelt_search_articles5 fields changed- added
Output schema / properties / effectiveQueryAdded value: +{ + "description": "Echoed query string for use in follow-up calls.", + "type": "string" +} - removed
Output schema / properties / queryRemoved value: -{ - "description": "Echoed query string for use in follow-up calls.", - "type": "string" -} - added
Output schema / properties / totalCountAdded value: +{ + "description": "Number of articles returned in this response.", + "type": "number" +} - removed
Output schema / properties / totalReturnedRemoved value: -{ - "description": "Number of articles returned in this response.", - "type": "number" -} - changed
Output schema / requiredPrevious value: -[ - "articles", - "totalReturned", - "query" -]New value: +[ + "articles", + "effectiveQuery", + "totalCount" +]
- Changed
gdelt_search_tv5 fields changed- added
Output schema / properties / effectiveQueryAdded value: +{ + "description": "Echoed query string for use in follow-up calls.", + "type": "string" +} - changed
Output schema / properties / notice / descriptionPrevious value: -"Recovery hint when no coverage was found. Absent on successful responses."New value: +"Recovery hint when no TV coverage was found. Absent on successful responses." - removed
Output schema / properties / queryRemoved value: -{ - "description": "Echoed query string.", - "type": "string" -} - added
Output schema / properties / totalCountAdded value: +{ + "description": "Number of station series returned.", + "type": "number" +} - changed
Output schema / requiredPrevious value: -[ - "query", - "dateResolution", - "timeRange", - "series", - "normalized" -]New value: +[ + "dateResolution", + "timeRange", + "series", + "normalized", + "effectiveQuery", + "totalCount" +]
9 tool updates
- First observed
gdelt_get_coverage_breakdown - First observed
gdelt_get_coverage_timeline - First observed
gdelt_get_tone_distribution - First observed
gdelt_get_tv_clips - First observed
gdelt_get_tv_context - First observed
gdelt_get_tv_trending - First observed
gdelt_list_tv_stations - First observed
gdelt_search_articles - First observed
gdelt_search_tv
Frequently Asked Questions
Claiming proves that you control a remote MCP connector. It does not move, proxy, or interrupt the server.
Open the connector listing, choose Claim ownership, and sign in to Glama.
Complete one verification method:
GitHub identity — fastest for official registry listings. For a namespace such as
io.github.alice/server, link the matching GitHub user, then choose Claim with GitHub. An organization namespace such asio.github.acme/serveralso needs that organization to have installed the Glama AI GitHub App and approved its permissions, because GitHub discloses organization membership only to apps it has installed. Use HTTP or DNS when it has not.HTTP challenge — works when you can deploy a public file. Generate a token, publish the exact JSON Glama shows at
/.well-known/glama.jsonon the same origin as the connector, then choose Check HTTP challenge.DNS challenge — works when you control DNS but cannot change the server. Generate a token, create the exact TXT record Glama shows, wait for it to propagate, then choose Check DNS challenge.
After verification, Glama sends a confirmation email and gives you access to listing details, thumbnails, health checks, and analytics. Keep the HTTP file or DNS record in place: Glama periodically checks it and ownership remains verified while the token is discoverable.
The HTTP ownership file has this structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"claim": "glama_claim_..."
}Claim tokens are opaque, stable, and bound to the signed-in Glama account. They contain no email address or other personal information. If Glama can no longer discover a verified HTTP or DNS token, it starts a seven-day grace period before removing claim-based access. Restore the same token during that period to keep ownership verified. Never publish an email address, Glama session token, GitHub token, or connector credential as ownership proof.
If verification fails, confirm that you copied the current token exactly. The HTTP file must be public, return valid JSON with a successful HTTP response, and stay on the connector's origin. DNS changes may need more time to propagate. A claim cannot transfer to a different origin or hostname: if the connector target changes, Glama starts the grace period and the new target must be claimed separately after the previous claim is released.
For a connector linked to the official MCP Registry, registry updates continue to replace its name, description, and URL by default. After claiming, open Manage connector and enable Use Glama listing details as the source of truth if edits made on Glama should be preserved. Categories and thumbnails are always managed on Glama; registry linkage and technical connection settings continue to sync.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
To improve your MCP server's ranking:
Claim ownership of the server listing
Complete the server profile with an accurate description and thumbnail
Provide a test profile so Glama can connect to and evaluate the server
Keep tool definitions clear and complete to earn a high Tool Definition Quality Score (TDQS)
Route real usage through the Glama Gateway; more recorded successful server uses also improve the ranking
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!
Related MCP Connectors
Geopolitical event detection, tone timeseries, actor trends from GDELT 2.0.
GDELT MCP — Global Database of Events, Language, and Tone (free, no auth)
Real-time news search across 500,000+ sources in 60+ languages with sentiment and entities.
Live global news signals: ranked wire, story timelines, coverage volume/tone/surges. Free, no auth.
Related MCP Servers
- FlicenseNot gradedqualityDmaintenanceEnables macro/geopolitical event detection by wrapping the GDELT 2.0 API, providing tools for searching events, trending actors, and sentiment timeseries from global news.1-
- AlicenseAqualityDmaintenanceProvides access to the GDELT DOC 2.0 API for searching global news articles and images across 65 languages with customizable timespans and query options.2142MIT
- AlicenseNot gradedqualityBmaintenanceA remote, read-only MCP server for global media intelligence using GDELT DOC 2.0 API, enabling search and analysis of multilingual news coverage, tone, and attention trends.MIT
- FlicenseNot gradedqualityCmaintenanceMCP server for querying GDELT news data, enabling article search and sentiment/volume timeline analysis via Cloudflare Workers.-
Glama MCP Gateway
Add one secure layer between your agents and this server.
TDQS
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.
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.
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.
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.