MCP NewsAPI.ai

search_events

Read-only

Search news EVENTS: clusters of articles about the same real-world happening, with a title, summary, date, location, key concepts and article count.

Instructions

Search news EVENTS: clusters of articles about the same real-world happening, with a title, summary, date, location, key concepts and article count. Best for "what is happening with X" — one event replaces dozens of near-duplicate articles. Cost: 5 tokens (measured live) per call within the last 31 days (default); allow_archive=true costs extra per year touched. At least one of keyword / concept_uris / category_uris / source_uris / location_uris is required. Defaults to 10 events, newest first; use sort_by="size" for the biggest stories. Use get_event for details on one. For companies, people, places or organisations, resolve them with suggest_concepts first and pass concept_uris; keyword is for free terms/topics and is noisy with common words (e.g. "Telefónica" also matches the Spanish adjective "telefónica").

Input Schema

TableJSON Schema

Name	Required	Description
`lang`	No	3-letter ISO 639-3 language codes, e.g. "spa" or ["eng", "spa"]. OR-ed. Accepts a single string or an array of strings.
`page`	No	Result page, starting at 1 (default 1).
`count`	No	Events per page, 1-50 (default 10).
`keyword`	No	Free-text keyword or phrase, for topics and general terms (e.g. "inflation", "wildfire"). Do NOT use it for companies, people, places or organisations: common words double as names (e.g. "Telefónica" also matches the ordinary Spanish adjective "telefónica") and produce irrelevant results. For those entities call suggest_concepts first and pass the returned URI in concept_uris.
`sort_by`	No	Sort order (default date). "size" = most articles first.
`date_end`	No	Latest date, YYYY-MM-DD (inclusive); must be >= date_start. With allow_archive the date_start → date_end (default today) span may be at most 1 year.
`sort_asc`	No	Ascending order (default false).
`date_start`	No	Earliest date, YYYY-MM-DD (inclusive). Must be within the last 31 days unless allow_archive=true, which makes date_start mandatory.
`source_uris`	No	News source URIs, e.g. "bbc.co.uk" (use suggest_sources). OR-ed. Accepts a single string or an array of strings.
`summary_len`	No	Max summary characters per event, 0-2000 (default 300).
`concept_uris`	No	Concept URIs for entities: companies, people, places, organisations. PREFERRED over keyword for any named entity: first call suggest_concepts (free) to resolve the name, then pass the returned `uri` here. Multiple values are OR-ed and far more precise than keyword, which avoids homonym noise. Accepts a single string or an array of strings.
`allow_archive`	No	Default false: search only the last 31 days (cheapest). Set true to reach the historical archive, which costs extra tokens per year queried; requires date_start and a range of at most 1 year.
`category_uris`	No	Category URIs, e.g. "news/Business" (use suggest_categories). OR-ed. Accepts a single string or an array of strings.
`location_uris`	No	Location URIs where the news happened (use suggest_locations). OR-ed. Accepts a single string or an array of strings.
`min_articles_in_event`	No	Only events covered by at least this many articles (filters noise).

Schema Changelog

Changes observed during successful MCP inspections.

Changed21 schema fields changedv1.0.2Oct 22, 2026

addedInput schema / properties / category_uris / anyOf

Added value: +[
+  {
+    "type": "string"
+  },
+  {
+    "items": {
+      "type": "string"
+    },
+    "type": "array"
+  }
+]

changedInput schema / properties / category_uris / description

Previous value: -"Category URIs, e.g. \"news/Business\" (use suggest_categories). OR-ed."New value: +"Category URIs, e.g. \"news/Business\" (use suggest_categories). OR-ed. Accepts a single string or an array of strings."

removedInput schema / properties / category_uris / items
```
Removed value: -{
-  "type": "string"
-}
```
removedInput schema / properties / category_uris / type
```
Removed value: -"array"
```

addedInput schema / properties / concept_uris / anyOf

Added value: +[
+  {
+    "type": "string"
+  },
+  {
+    "items": {
+      "type": "string"
+    },
+    "type": "array"
+  }
+]

changedInput schema / properties / concept_uris / description

Previous value: -"Concept URIs (entities such as people, companies, places) — obtain them with suggest_concepts. Multiple values are OR-ed. Far more precise than keyword."New value: +"Concept URIs for entities: companies, people, places, organisations. PREFERRED over keyword for any named entity: first call suggest_concepts (free) to resolve the name, then pass the returned `uri` here. Multiple values are OR-ed and far more precise than keyword, which avoids homonym noise. Accepts a single string or an array of strings."

removedInput schema / properties / concept_uris / items
```
Removed value: -{
-  "type": "string"
-}
```
removedInput schema / properties / concept_uris / type
```
Removed value: -"array"
```

changedInput schema / properties / keyword / description

Previous value: -"Free-text keyword or phrase to search for."New value: +"Free-text keyword or phrase, for topics and general terms (e.g. \"inflation\", \"wildfire\"). Do NOT use it for companies, people, places or organisations: common words double as names (e.g. \"Telefónica\" also matches the ordinary Spanish adjective \"telefónica\") and produce irrelevant results. For those entities call suggest_concepts first and pass the returned URI in concept_uris."

addedInput schema / properties / lang / anyOf

Added value: +[
+  {
+    "pattern": "^[a-z]{3}$",
+    "type": "string"
+  },
+  {
+    "items": {
+      "pattern": "^[a-z]{3}$",
+      "type": "string"
+    },
+    "type": "array"
+  }
+]

changedInput schema / properties / lang / description

Previous value: -"3-letter ISO 639-3 language codes, e.g. [\"eng\", \"spa\"]. OR-ed."New value: +"3-letter ISO 639-3 language codes, e.g. \"spa\" or [\"eng\", \"spa\"]. OR-ed. Accepts a single string or an array of strings."

removedInput schema / properties / lang / items
```
Removed value: -{
-  "type": "string"
-}
```
removedInput schema / properties / lang / type
```
Removed value: -"array"
```

addedInput schema / properties / location_uris / anyOf

Added value: +[
+  {
+    "type": "string"
+  },
+  {
+    "items": {
+      "type": "string"
+    },
+    "type": "array"
+  }
+]

changedInput schema / properties / location_uris / description

Previous value: -"Location URIs where the news happened (use suggest_locations). OR-ed."New value: +"Location URIs where the news happened (use suggest_locations). OR-ed. Accepts a single string or an array of strings."

removedInput schema / properties / location_uris / items
```
Removed value: -{
-  "type": "string"
-}
```
removedInput schema / properties / location_uris / type
```
Removed value: -"array"
```

addedInput schema / properties / source_uris / anyOf

Added value: +[
+  {
+    "type": "string"
+  },
+  {
+    "items": {
+      "type": "string"
+    },
+    "type": "array"
+  }
+]

changedInput schema / properties / source_uris / description

Previous value: -"News source URIs, e.g. \"bbc.co.uk\" (use suggest_sources). OR-ed."New value: +"News source URIs, e.g. \"bbc.co.uk\" (use suggest_sources). OR-ed. Accepts a single string or an array of strings."

removedInput schema / properties / source_uris / items
```
Removed value: -{
-  "type": "string"
-}
```
removedInput schema / properties / source_uris / type
```
Removed value: -"array"
```

First observedv1.0.0Oct 19, 2026

TDQS

A4.6/5.0

Behavior4/5

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

Beyond readOnlyHint, it discloses a concrete cost model (5 tokens per call in the 31-day window, extra per archive year), the at-least-one-filter requirement that the schema's empty `required` array does not convey, and the default ordering. It stops short of describing pagination limits or result-count behavior for the event list, but the operational constraints are unusually well surfaced.

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?

Front-loaded with the resource definition and the payoff ("one event replaces dozens of near-duplicate articles"), then cost, then the required-filter constraint, then routing guidance. Dense but nearly every sentence carries decision-relevant information; the token-cost phrase is slightly parenthetical but not wasteful.

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?

For a 15-parameter, no-output-schema search tool, the description covers the resource model, cost model, mandatory filter rule, defaults, sorting strategy, and per-filter routing to sibling suggest_* tools. An agent can construct a correct call without consulting anything else.

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 baseline is 3; the description still adds selection guidance the schema cannot, e.g. preferring concept_uris over keyword because of homonym noise and choosing sort_by="size" for biggest stories. The per-year archive cost implication of allow_archive also extends the schema's terse note.

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?

States a specific verb and resource ("Search news EVENTS") and immediately defines the resource as clusters of articles about one real-world happening, listing the fields returned. It explicitly separates itself from search_articles (event vs article granularity) and points to get_event for single-event detail.

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

Usage Guidelines5/5

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

Gives an explicit use case ("what is happening with X"), an explicit exclusion (don't use keyword for named entities), and names the routing tools: suggest_concepts for entities, suggest_sources/suggest_categories/suggest_locations for other filters, get_event for details. It also explains the cost trade-off that governs when to use allow_archive.

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

Deploy Server

search_events

Instructions

Input Schema

Schema Changelog

TDQS

Other Tools