SiteCheck Web Intel

Recent news articles that match a query, from GDELT's

search_gdelt_news

Read-only

Recent news articles (last ~72 hours) that match a query, from GDELT's public Context 2.0 API (DOC 2.0 API as fallback), no key: title, URL, domain, language, time seen and the matching sentence. Supports GDELT query syntax ("exact phrase", sourcelang:english, domain:bbc.co.uk). Covers the sources GDELT monitors, not every outlet. Rate-limited or slow GDELT answers return 503. Takes about 14 s; allow a 30 s timeout. Related tools on this server, for a different need: search_ap_news_articles when you need Latest Associated Press articles: headline, publisher; search_bbc_news_articles when you need BBC News top stories from the public BBC RSS feed. Price: $0.002 in USDC per successful call, paid with x402 (Base, Solana or Arc); failed calls are not charged.

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": {
      "q": "<q>"
    },
    "name": "search_gdelt_news"
  }
}

Input Schema

Name	Required	Description	Default
`q`	Yes	Search words or GDELT query (1 to 200 characters)
`limit`	No	How many articles, 1 to 50 (default 10)

Output Schema

Name	Required	Description	Default
`q`	No
`count`	No
`items`	No
`source`	No
`checkedAt`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 23, 2026

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 it discloses things the annotations cannot: no API key required, coverage limited to sources GDELT monitors, rate-limited answers returning 503, ~14 s latency with a suggested 30 s timeout, and a paid x402 model where failures are not charged. These are exactly the operational traits an agent needs before invoking and while handling errors.

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?

Purpose and time window are front-loaded, and subsequent sentences cover syntax, coverage limits, latency, and pricing without padding. The parenthetical '(DOC 2.0 API as fallback)' and the pricing clause add some length, but each carries actionable information, so nothing is genuinely wasted.

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?

An output schema exists, so return values need not be explained, and the description instead covers the non-obvious risks of this specific tool: partial source coverage, 503 on slow/rate-limited answers, multi-second latency requiring a longer timeout, and per-call cost. Nothing an agent needs in order to call it correctly is missing.

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 schema already documents 'q' and 'limit' and the baseline would be 3. The description earns above baseline by explaining the GDELT query grammar with concrete examples ('exact phrase', sourcelang:english, domain:bbc.co.uk), which materially changes how the agent should format 'q'; 'limit' gets no extra treatment beyond the schema.

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 names a specific verb and resource ('Recent news articles ... that match a query') and pins down the backing sources (GDELT Context 2.0, DOC 2.0 fallback), the time window (~72 hours), and the returned fields (title, URL, domain, language, time seen, matching sentence). It is distinguishable from the AP and BBC siblings without opening any schema.

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 explicitly routes the agent elsewhere for two named alternatives ('search_ap_news_articles when you need Latest Associated Press articles', 'search_bbc_news_articles when you need BBC News top stories'), each with a triggering condition. It does not, however, state when GDELT is the wrong choice versus the many other news siblings (e.g. search_google_news), so coverage of alternatives is partial rather than exhaustive.

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

All SiteCheck Web Intel tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?