Skip to main content
Glama

gdelt-mcp-server

by io.github.cyanheads

Get GDELT TV Clips

gdelt_get_tv_clips
Read-only

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.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
sortNoSort order: relevance (default), dateDesc (newest first), dateAsc (oldest first).relevance
queryYesSearch query for TV transcript content. Same TV operators as gdelt_search_tv: station:CNN, network:CBS, market:"National", show:"Anderson Cooper", context:"vaccine".
stationsNoStation 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.
timespanNoTime window, e.g. "1m", "6m". Ignored when startDatetime/endDatetime are set. TV data spans 2009–October 2024.
maxRecordsNoMaximum 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.
endDatetimeNoEnd 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.
startDatetimeNoStart 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

TableJSON Schema
NameRequiredDescriptionDefault
clipsNoMatching TV clips sorted per the sort parameter.
errorNoPresent when the call failed. Absent on success.
noticeNoDisclosure 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.
totalCountNoNumber of clips returned.
effectiveQueryNoEchoed query string for use in follow-up calls.
continuationWindowsNoThe 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

A4.5/5.0
Behavior5/5

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.

Conciseness5/5

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.

Completeness5/5

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.

Parameters3/5

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.

Purpose5/5

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.

Usage Guidelines4/5

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.

All gdelt-mcp-server toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.6/5.0
Disambiguation5/5

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

Naming Consistency5/5

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

Tool Count5/5

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

Completeness5/5

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

Resources