Skip to main content
Glama

Search GDELT GKG Themes

gdelt_search_themes
Read-only

Find GDELT Global Knowledge Graph (GKG) theme identifiers for the theme: operator that gdelt_search_articles, gdelt_get_coverage_timeline, gdelt_get_tone_distribution, and gdelt_get_coverage_breakdown accept in query. Searches the identifiers in the GDELT GKG theme lookup, which carries no labels or descriptions: every query word must begin one of the _-separated parts of an identifier or run across consecutive parts, or all the words joined must, so "drought" finds NATURAL_DISASTER_DROUGHT, "cyberattack" finds CYBER_ATTACK, "plant disease" finds TAX_PLANTDISEASE, and "wb water" narrows to World Bank water themes. There is no stemming or synonym matching — "displacement" does not reach DISPLACED — except one fallback: when nothing matches, the search retries once with a trailing s dropped from each word of four or more letters, and says so. Matches rank an exact identifier first, then by the count the lookup lists — a static prevalence figure, not a live article total — and each carries a paste-ready operator such as theme:TAX_DISEASE_OUTBREAK. Page with offset and limit (up to 100 matches per page; a larger limit runs at 100).

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "query": "<query>"
    },
    "name": "gdelt_search_themes"
  }
}

Input Schema

NameRequiredDescriptionDefault
limitNoMaximum matches returned in this response. Values above 100 run at 100 with a limitClamp disclosure when clamping is enabled.
queryYesWords to find in theme identifiers (e.g. "drought", "cyber attack", "refugee"), a family prefix with a word ("wb water", "crisislex"), or a whole identifier to confirm it is listed ("TAX_DISEASE_OUTBREAK"). Case-insensitive; a leading theme: is ignored; every word must match, or all the words joined must ("plant disease" matches TAX_PLANTDISEASE). Must contain at least one letter or digit.
offsetNoZero-based offset into the ranked matches. Use nextOffset from the preceding response with the same query to retrieve the next page.

Output Schema

NameRequiredDescriptionDefault
errorNoPresent when the call failed. Absent on success.
limitNoMaximum matches this page holds — the requested limit, or 100 when a larger one was clamped.
noticeNoSearch outcome: that the plural fallback supplied the matches and which words it tried, or, when nothing matched, how to retry. Absent when the query as given matched.
offsetNoZero-based offset of this page.
matchesNoMatches on this page: an exact identifier match first, then by count descending, then by identifier.
limitClampNoPresent only when the requested count exceeded the per-call cap: the call ran exactly as a call at the cap, and every count, notice, and continuation in this response reflects the applied value.
nextOffsetNoOffset for the next page with the same query. Absent when this is the final page.
totalCountNoTotal themes matching the query — the same figure as totalMatches.
totalMatchesNoTotal themes matching the query, across all pages.
effectiveQueryNoEchoed query string for use in follow-up calls.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changed
    • changedInput schema / properties / limit / description
      Previous value: -"Maximum matches returned in this response (1–100; a value up to 1000 runs at 100, and the response says so in limitClamp)."New value: +"Maximum matches returned in this response. Values above 100 run at 100 with a limitClamp disclosure when clamping is enabled."
    • removedInput schema / properties / limit / maximum
      Removed value: -1000
    • addedInput schema / properties / limit / multipleOf
      Added value: +1
    • changedInput schema / properties / limit / type
      Previous value: -"integer"New value: +"number"
  2. Changed4 schema fields changed
    • changedInput schema / properties / limit / description
      Previous value: -"Maximum matches returned in this response (1–100)."New value: +"Maximum matches returned in this response (1–100; a value up to 1000 runs at 100, and the response says so in limitClamp)."
    • changedInput schema / properties / limit / maximum
      Previous value: -100New value: +1000
    • changedOutput schema / properties / limit / description
      Previous value: -"Maximum matches requested for this page."New value: +"Maximum matches this page holds — the requested limit, or 100 when a larger one was clamped."
    • addedOutput schema / properties / limitClamp
      Added value: +{
      +  "additionalProperties": false,
      +  "description": "Present only when the requested count exceeded the per-call cap: the call ran exactly as a call at the cap, and every count, notice, and continuation in this response reflects the applied value.",
      +  "properties": {
      +    "applied": {
      +      "description": "The per-call cap the call ran with instead.",
      +      "type": "number"
      +    },
      +    "parameter": {
      +      "description": "The count input that was clamped.",
      +      "enum": [
      +        "maxRecords",
      +        "limit"
      +      ],
      +      "type": "string"
      +    },
      +    "requested": {
      +      "description": "The value the call asked for.",
      +      "type": "number"
      +    }
      +  },
      +  "required": [
      +    "parameter",
      +    "requested",
      +    "applied"
      +  ],
      +  "type": "object"
      +}
  3. Added

TDQS

A4.6/5.0
Behavior5/5

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

Beyond the readOnly/openWorld annotations, the description discloses the lookup's no-label nature, exact matching rules, lack of stemming/synonyms, the trailing-s fallback, ranking order, static prevalence counts, paste-ready operator output, and pagination/clamping behavior. This is rich behavioral context and is consistent with the annotations.

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

Conciseness4/5

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

The purpose is front-loaded and most sentences carry operational detail. It is dense and slightly long, but the length is justified by the unusual matching and fallback rules rather than filler.

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 presence of annotations and an output schema, the description covers what an agent needs to call the tool correctly: when to use it, how queries are interpreted, how ranking works, and how paging behaves. No material gap remains.

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

Parameters4/5

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

Schema coverage is 100%, so the parameter schema already carries much of the burden. The description still adds useful semantics, especially how query matching works across identifier parts, fallback behavior, and how limit/offset pagination behaves in practice.

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 verb and resource: find GDELT GKG theme identifiers usable as the theme: operator in several named sibling tools. It clearly distinguishes this lookup tool from article or coverage search siblings by framing it as the identifier lookup that feeds their query operators.

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

Usage Guidelines4/5

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

It gives clear context for when to use it: obtaining theme identifiers accepted by gdelt_search_articles, coverage tools, and tone tools. It does not explicitly state when not to use it or offer a named alternative, but the use case is unambiguous.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.