Global news MCP server for AI agents. Search and retrieve international news, discover publishers, and explore coverage across 234 countries. Provides structured, categorized, and deduplicated news through four tools: search_news, get_latest_news, get_sources, and get_coverage.
Scored across 4 tools
Each tool has a reasonably distinct role: metadata (get_coverage), publisher directory (get_sources), browsing newest articles (get_latest_news), and keyword/date-filtered search (search_news). The main overlap is between get_latest_news and search_news, since search without keywords defaults to the newest articles from the last day, but the search-specific filters and sorting make the boundary understandable.
All names use snake_case and follow a predictable verb_noun shape. The only minor deviation is the mix of 'get_' and 'search_' verbs, but that distinction is meaningful (retrieval of metadata/directories vs. querying articles).
Four tools is well-scoped for a read-only news monitoring service: coverage metadata, publisher listing, latest news, and search. Each tool earns its place without redundancy.
The surface covers the core read-only workflows: discovering valid filters, finding publishers, browsing latest articles, and searching by keyword/date. Minor gaps exist, such as no explicit article-detail fetch or pagination parameter beyond '25 per page', but the included URLs let agents work around this.
The countries, languages and topics (macro categories) World Feed Monitor covers, with the codes to filter by: a country's iso_2 or iso_3, a language's code, a topic's key. Pass `include` to ask for only some of them.| Name | Required | Description | Default |
|---|---|---|---|
| include | No | Which lists to return. Default: all three. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
readOnlyHint=true already covers the safety profile, and the description adds real content context: what entity lists come back, which code identifies each, and that all three are returned by default. It stops short of stating whether the lists are static or paginated, but for a small reference dataset that gap is minor.
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?
A single sentence, front-loaded with the resource, then the identifying codes, then the optional narrowing parameter. No filler or 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 zero-required-parameter read-only lookup with no output schema, the description sufficiently describes the payload shape (lists plus their codes) so an agent knows what it will receive. Only the response envelope/ordering is left unspecified, which is low risk here.
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% and the `include` parameter is already documented, so the baseline is 3. The description goes beyond it by explaining what each list contains and which code field maps to it, giving the enum values meaning the schema alone does not.
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?
Names a specific resource (the countries, languages and topics World Feed Monitor covers) and the exact code formats returned (iso_2/iso_3, language code, topic key). It reads as a reference-data lookup, which implicitly separates it from the news/search siblings, though it never names them.
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?
Usage is only implied: the mention of 'codes to filter by' suggests it should be called before search_news, but the description never says when to use this versus get_sources or get_latest_news, nor any exclusions. The only explicit instruction is about the optional `include` parameter.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The newest news articles from the last day, newest first, 25 per page. Optionally narrowed by topic, country, language or publisher. Each article carries its publisher and URL.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Page of 25, from 1. | |
| source | No | Publisher keys from get_sources. | |
| country | No | Country ISO codes, two or three letters. | |
| language | No | Language codes, e.g. "en". | |
| macro_category | No | Topic keys, e.g. "politics". See get_coverage. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true. The description adds behavior beyond that: a one-day window, newest-first ordering, 25-item pagination, and the fact that each article includes publisher and URL. It stops short of describing rate limits or whether empty results are possible.
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?
Two tight sentences; the core scope leads and the optional filters and returned fields follow. No boilerplate 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?
For a read-only, fully documented 5-parameter tool with no output schema, the description covers window, ordering, page size, filters, and returned fields. It could add a bit more routing context against search_news, but nothing needed to invoke it correctly 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?
Schema coverage is 100%, so the schema already documents page, source, country, language, and macro_category. The description restates the filterable dimensions (topic, country, language, publisher) without adding syntax or constraints, so baseline 3 applies.
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?
States a specific resource and scope: newest articles from the last day, newest first, 25 per page. It does not explicitly name search_news as the alternative, so sibling differentiation is only implicit.
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 last-day, newest-first framing implies when to use it for recent news, and it notes optional narrowing by topic, country, language, or publisher. But it never states when to prefer search_news or get_sources, nor any exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the news publishers World Feed Monitor reads, alphabetically, optionally for one country. Each has a key to pass as `source` to search_news or get_latest_news, its homepage, and its type and sector where classified.| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Page, from 1. | |
| country | No | Country ISO code, two or three letters. | |
| per_page | No | Publishers per page. Default 50. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the safety profile is covered. The description adds value beyond that by disclosing the return shape (key, homepage, type, sector) and the alphabetical ordering, which is important for pagination behavior. No output schema exists, so this disclosure is genuinely useful.
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?
Two compact sentences with zero padding; the core purpose is stated first, then the practical detail about the key field. Every clause earns its place.
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 read-only listing tool with no output schema, the description covers purpose, filtering, ordering, and the fields returned, which is everything an agent needs to call it and interpret the result. Nothing material 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?
Schema description coverage is 100%, so pagination and country parameters are documented in the schema and the baseline is 3. The description adds one thing the schema does not: results are sorted alphabetically, which matters for reasoning about paging, and it restates the country filter as an optional scope.
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?
States a specific verb and resource ('List the news publishers World Feed Monitor reads') plus ordering and an optional filter. It is clearly a directory/lookup tool, distinguishable from siblings like search_news and get_latest_news, which it explicitly references.
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 explains the downstream workflow: each entry has a key to pass as `source` to search_news or get_latest_news, which tells the agent exactly why and when to call this tool. It lacks an explicit exclusion statement (e.g., 'do not use this to fetch articles'), keeping it at 4.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search news articles from publishers worldwide. Returns 25 articles per page, each with its publisher and URL. With keywords or title the best matches come first; otherwise the newest. Pass sort to choose.
Without from_date and to_date the search covers the last day. Filters take lists; values within one filter are alternatives (OR), different filters narrow each other (AND). Use get_coverage for valid country, language and topic codes, and get_sources for publisher keys.| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Page of 25, from 1. | |
| sort | No | relevance: best match first, then newest. desc/asc: by publication date. Default relevance with keywords or title, otherwise desc. | |
| title | No | Words to match in the title only. | |
| sector | No | Publisher sector keys. | |
| source | No | Publisher keys from get_sources. | |
| country | No | Country ISO codes, two or three letters, e.g. "IT" or "ITA". | |
| to_date | No | Latest publication date, YYYY-MM-DD. | |
| keywords | No | Words to match in the title and text. | |
| language | No | Language codes, e.g. "en". | |
| continent | No | Continent keys. | |
| from_date | No | Earliest publication date, YYYY-MM-DD. | |
| has_image | No | Only articles with (true) or without (false) an image. | |
| source_type | No | Publisher type keys. | |
| macro_category | No | Topic keys, e.g. "politics". See get_coverage. | |
| continent_region | No | Continent region keys. | |
| publisher_category | No | Publishers' own category names. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond readOnlyHint=true, the description discloses genuinely important behavior: page size of 25, a default one-day search window when from_date/to_date are omitted, default sort behavior, and the OR-within/AND-across logic for list filters. These are the exact traps an agent would otherwise hit.
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?
Four sentences, each carrying distinct information: return shape, ranking defaults, default date window, and filter composition. The most consequential constraint (one-day default) is stated plainly rather than buried.
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 16 optional parameters and no output schema, the description does the necessary work: it describes the return payload and the filter algebra. Minor gaps remain around pagination limits beyond the schema's maximum and what an empty result looks like, but nothing blocking.
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, but the description adds real meaning on top: that filters take lists, values within one filter are OR, and different filters AND together, plus the default date range. That combination semantics is not visible in the schema.
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 news articles from publishers worldwide") and states the return shape (25 articles per page with publisher and URL). It references helper siblings get_coverage and get_sources, but never contrasts itself with get_latest_news, leaving that sibling relationship to inference.
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 explains the selection logic well: with keywords or title the best matches come first, otherwise the newest, and sort can override. It also routes agents to get_coverage and get_sources for valid codes. What's missing is an explicit "use get_latest_news instead when…" exclusion.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.