NewsMCP

Server Details

Live world news deduplicated into story events, with corroboration counts and source links.

If you are the author of this connector, you can claim ownership with GitHub, an HTTP challenge, or a DNS record. Claimed connector authors can inspect health checks, view analytics, and manage their listing.

Status: Healthy
Uptime: 99.6% over 22 days
Last Tested: 2026-09-27 02:28
Transport: Streamable HTTP · MCP 2025-11-25
URL

TDQS

A4.4/5.0

Scored 2026-09-17 13:26 across 5 tools

Disambiguation4/5

news and get_story are both retrieval paths—news can fetch a story by id while get_story expands one—so an agent could initially pick either; check_coverage also overlaps somewhat with news's corroboration ranking. The check_* tools are otherwise sharply distinct, and the descriptions do enough to steer correct selection.

Naming Consistency3/5

Three tools consistently use check_* for inspection/verification tasks, but the primary search tool is the bare noun news and the detail tool uses get_story. This mixes noun-as-command with verb_noun patterns, though each name is still readable and the check_ prefix gives some structure.

Tool Count5/5

Five tools is a well-scoped size for a news analysis API, covering search, detail expansion, verification, budget inspection, and health diagnostics. None feels redundant; check_health is a small but legitimate operational addition.

Completeness4/5

The surface covers the core news workflow: find stories, expand a story, verify coverage, and monitor API limits. Minor gaps exist, such as no explicit source-level search or comparison beyond get_story, but agents can accomplish the stated purpose without dead ends.

Available Tools

5 tools

check_coverageA

Read-only

Inspect

Judge how widely and how independently a claim has been reported.

Answers "is this real?" rather than returning a list. Reports the number of INDEPENDENT newsrooms — outlets that reported it themselves — separately from the number of domains that carried it, which includes syndication. A story on 200 domains from 3 newsrooms is one story reprinted, not 200 confirmations.

Because upstream clustering splits a story across languages, this totals the likely variants of the same story and presents that total as an upper bound, listing what was combined so the caller can check it is really one story.

ParametersJSON Schema

Name	Required	Description	Default
`claim`	Yes	The claim or headline to check, phrased in the words a headline would use. Matched literally against headlines and summaries, not by meaning, so "atomic arsenal" will not find stories about nuclear weapons.
`api_key`	No	Optional NewsMCP API key for this call; forwarded upstream as x-api-key. Only one request may be in flight at a time, so never call in parallel.
`days_back`	No	How far back to look, in days. Defaults to 14. Clamped down to whatever the caller's plan allows, with a note saying so.
`response_format`	No	markdown (default), text, or json. Pass the format the user asked for rather than reformatting afterwards.	markdown

Output Schema

ParametersJSON Schema

Name	Required	Description
`notes`	Yes	Query-normalization and plan-clamping notes to relay verbatim.
`matched`	Yes	Whether any story matched the claim text in the window.
`variants`	Yes	Anchor story first, then its likely variants.
`anchor_newsrooms`	Yes	Independent newsrooms for the best-corroborated matching story.
`total_matching_stories`	Yes
`combined_newsrooms_upper_bound`	Yes	Sum across clustered variants of the same story — an upper bound, not a confirmed count.

TDQS

A4.1/5.0

Behavior4/5

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

The description adds valuable behavioral context beyond the annotations: it explains the difference between independent newsrooms and domains, and that it totals story variants as an upper bound due to language clustering. Annotations already declare readOnlyHint, openWorldHint, and destructiveHint, so the description enhances transparency without contradicting them.

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?

Every sentence earns its place. The description opens with a clear purpose, then explains the independence concept with a concrete example, and finally addresses the clustering behavior with a note on verification. It is well-structured, front-loaded, and free of fluff.

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?

The description covers the tool's core logic thoroughly, including the independent vs syndicated distinction and the upper-bound aggregation. Given that an output schema exists (not shown), the description does not need to explain return values. It is complete for an agent to understand how and when to use it.

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 baseline is 3. The description does not add much about parameters; it focuses on output semantics. The claim parameter's literal matching is already described in the schema. The description's note about clustering does not directly clarify parameter usage, so it remains at baseline.

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 clearly states the tool's specific function: judging how widely and independently a claim has been reported. It distinguishes itself from siblings by emphasizing it answers 'is this real?' rather than returning a list, which differentiates it from get_story or news. The distinction between independent newsrooms and syndicated domains is a clear, unique purpose.

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

Usage Guidelines3/5

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

The description implies usage for verification ('is this real?') but does not explicitly name alternatives or state when not to use it. It doesn't say 'use get_story for story details' or 'use news for a list'. However, the focus on coverage analysis gives implicit guidance, and the clarification that it doesn't return a list helps agents avoid misusing it.

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

check_healthA

Read-only

Inspect

Check whether the NewsMCP REST API is reachable and healthy.

Does not require an API token. Use when diagnosing connectivity, not for searching news. For allowances and remaining budget use check_limits instead.

Returns: str: Health status reported by the API.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.7/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so safety profile is covered. Description adds that no API token is required and specifies the return type as a string health status, which is useful context beyond annotations.

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?

Two short paragraphs with the purpose front-loaded and no wasted words. The 'Returns' line clearly documents output, and the alternative tool reference is concise.

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 zero-parameter health check with annotations covering safety, the description provides everything an agent needs: purpose, usage context, authentication requirement, and return type. Nothing 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?

The tool has zero parameters, so there is nothing for the description to clarify beyond the schema. Baseline of 4 is appropriate since the schema is trivially complete and the description adds no parameter info, but none is needed.

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 ('Check') and resource ('NewsMCP REST API') with explicit health scope. Clearly distinguishes from sibling tools by saying it's not for searching news and points to check_limits for budget queries.

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?

Explicitly states when to use: 'when diagnosing connectivity', and when not to use: 'not for searching news'. Names the alternative tool `check_limits` for a different purpose.

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

check_limitsA

Read-only

Inspect

Report what this caller may do right now — and never spend any of it to find out.

Answers the questions the news tool descriptions cannot: how many searches are left this hour, how far back this plan reaches, the largest limit it allows, how many searches may run at once, and how long to wait if the budget is spent. These ceilings are per-plan and change without a release, so trust this over any number written into a description.

Checking is free: the endpoint is exempt from every metering stage, so calling it does not consume an hourly call, a concurrency slot, or a credit.

Reach for it before planning a batch of calls, and after any plan-limit or rate-limit error instead of guessing the ceiling that was hit.

ParametersJSON Schema

Name	Required	Description	Default
`api_key`	No	Optional NewsMCP API key. Report the ceilings for this key's plan; omit to report the keyless ceilings.
`response_format`	No	`text` (default) for a readable summary, `json` for the raw payload.	text

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.5/5.0

Behavior5/5

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

Annotations already mark this as read-only and non-destructive, and the description goes beyond that by disclosing that the endpoint is 'exempt from every metering stage' and consumes no hourly call, concurrency slot, or credit. It also warns that ceilings are per-plan and change without a release, adding important behavioral context not available from annotations or schema.

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 front-loaded with the core purpose, then efficiently expands with a bullet-like list of answered questions, a critical no-cost guarantee, and explicit when-to-use guidance. Every sentence earns its place; there is no filler or repetition of schema details.

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?

The tool has only two optional parameters, an output schema, and rich annotations, so the description's coverage of purpose, cost implications, plan-dependence, and usage timing is complete. An agent can confidently decide when and why to call check_limits without needing additional context.

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 both api_key and response_format are already fully documented. The description adds general context about per-plan ceilings, but it does not materially extend the semantic meaning of either parameter beyond what the schema already states.

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 opening sentence states a specific verb and resource: 'Report what this caller may do right now.' It then enumerates concrete metrics (searches left, plan reach, limit, concurrency, wait time), and explicitly contrasts itself with the `news` tool descriptions, which cannot answer these questions. This makes the tool's purpose unambiguous and separates it from its most likely confusing sibling.

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 guidance: use it before planning batch calls and after plan-limit or rate-limit errors, rather than guessing the ceiling. It does not explicitly compare with alternative siblings like check_coverage or check_health, but the intended triggers are specific and actionable.

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

get_storyA

Read-only

Inspect

Expand one story: full summary, classification, actors, and source links.

Use this after any search, when the user wants more than the digest line for a particular story. It is the only tool that can return a story's complete source list.

ParametersJSON Schema

Name	Required	Description	Default
`api_key`	No	Optional NewsMCP API key for this call; forwarded upstream as x-api-key. Only one request may be in flight at a time, so never call in parallel.
`event_id`	Yes	The `event_id` of a story from an earlier result (e.g. `evt_...`). A story folded into a more complete one answers 404 naming its replacement id — fetch that instead.
`include_sources`	No	False (default) returns a sample of source links; True returns every one. A large story can carry several hundred, so leave this off unless the user asked for the full list. This is the only place the complete list is available — the search endpoints cap it.
`response_format`	No	markdown (default), text, or json. Pass the format the user asked for rather than reformatting afterwards.	markdown

Output Schema

ParametersJSON Schema

Name	Required	Description
`size`	No	Article count.
`sector`	No
`reports`	No
`sources`	No	Source article URLs — a sample or the full list per verbosity.
`abstract`	No
`entities`	No	Key actors named in the story.
`event_id`	No	Stable id, e.g. evt_...
`headline`	No
`last_seen`	No	ISO 8601 UTC.
`newsrooms`	No	Independent newsrooms — the corroboration signal.
`one_liner`	No
`event_type`	No	family.leaf taxonomy value, e.g. deals.merger_acquisition.
`first_seen`	No	ISO 8601 UTC.
`content_type`	No
`source_count`	No	Publisher domains, mirrors included.
`language_count`	No

TDQS

A5/5.0

Behavior5/5

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

Annotations already mark the tool as read-only, open-world, and non-destructive, so the bar is lower. The description adds valuable behavior beyond that: folded stories can return a 404 naming a replacement id, source links are sampled by default and can number in the hundreds, and there is a concurrency warning about in-flight requests.

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 main description is two sentences with no filler: the first states the operation and contents, the second gives usage context. Supporting behavioral details live in the parameter descriptions where they belong, keeping the overall structure clean and front-loaded.

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?

With a rich schema, output schema present, and annotations already covering safety, the description adds the remaining operational context an agent needs: when to call it, why it is unique, how source lists behave, and how to handle 404 replacement ids. Nothing essential for invoking the tool correctly is missing.

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

Parameters5/5

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

Schema description coverage is 100%, so the baseline is 3, but the description adds substantial meaning beyond the schema: event_id has 404 replacement behavior, include_sources has a major trade-off (complete list only here, potentially hundreds of links), and response_format should match what the user asked for. This clearly exceeds the baseline.

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 opens with a specific verb-resource pair ('Expand one story') and lists exactly what is returned: full summary, classification, actors, and source links. It also distinguishes itself from search/digest tools by noting it is the only tool that can return a story's complete source list.

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?

The description explicitly says to use this after any search when the user wants more than the digest line for a particular story. It also names the key differentiator—complete source list is only available here—and the include_sources schema guidance reinforces when the full list should be left off.

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

newsA

Read-only

Inspect

Search already-synthesized news events — pre-built story digests — or fetch one by id.

Each story comes with a generated headline, one-liner, abstract, key actors, and industry/event-type labels. Use it for a quick digest of what happened, for deal/incident-type or industry filtering, and for corroboration ranking. Nothing is required: a bare call returns the most-corroborated stories of the last 24 hours. Limits — keyless: 7-day from_ lookback, 20 calls/hour, 20 stories per call, over-limit narrowed with a notice. With a key: per-plan ceilings (free tier today 14 days, 50 calls/hour, 50 stories), over-limit rejected rather than narrowed. Call check_limits for the live numbers; it is free and never spends the budget it reports on.

Filters combine with AND; event_type, content_type, and sector each accept several comma-separated values combined with OR.

ParametersJSON Schema

Name	Required	Description	Default
`q`	No	Optional search terms, matched case-insensitively against the story's headline, one-liner, abstract, and named actors (no article body text, no stemming). Space-separated words are ANDed, so ALWAYS quote a multi-word phrase: `layoffs OR "workforce reduction"` works, `layoffs OR workforce reduction` is read as a mix of AND/OR and rejected. Supports AND/OR/NOT (aliases &&, \|\|, !), ( ) grouping, and `*` wildcards. NEAR() and MULTIPLE() are NOT supported here — they are silently read as ordinary words instead of erroring, so never use them. Omit q entirely for a filter-only digest ("banking news today" needs no q at all).
`sort`	No	What "best" means for this call. Omit it unless the user asked for a specific ordering: the API then picks `relevance` when `q` or `subject` is set and `newsrooms` when neither is, which is almost always right. Forcing `newsrooms` on a keyword search ranks by story size rather than match, so `subject="Bank of America"` returns "India Now Asia's Least Preferred Stock Market" ahead of "Bank of America Warns of European Stock Decline" — big stories that merely mention the words. `newsrooms`: most independently-corroborated first. `trending`: corroboration weighted by freshness on an 8-hour half-life — the one for "what is blowing up right now". `relevance`: best semantic match to q first, and REQUIRES q. `last_seen`: most recently active. `first_seen`: most recently started. `size`: most articles. `source_count`: most publisher domains, mirrors included. `confidence`: highest label confidence, unlabeled last regardless of order.
`from_`	No	Inclusive lower bound on when the story BEGAN (its first_seen) — NOT the publish date of any one article, so a story still running today but started last week falls outside the default window. ISO 8601 (`2026-07-01T00:00:00`) or a relative phrase (`now-6h`, `2 days ago`, `yesterday`); all dates are UTC. Default: 24 hours ago, much narrower than a general news search — widening this is the FIRST thing to try when a query that should match something returns nothing — but the lookback is capped: 7 days keyless (narrowed with a notice), and per-plan with a key (14 days on the free tier today, rejected rather than narrowed). `check_limits` reports the caller's live ceiling.
`limit`	No	Stories per page, 1–50, default 20, but capped for the caller: keyless 20 (softly, with a notice), and per-plan with a key (50 on the free tier today, over it is a validation error naming the maximum). `check_limits` reports the live cap. Raise it when the user asks for breadth — one call with a a flat ceiling rather than a page size: there is no paging past it, since the hourly call budget is the scarce resource (keyless 20/hour, 50/hour on the free tier).
`sector`	No	Industry the story belongs to. Comma-separated for OR (`software_it_services,semiconductors` = "tech and chips"). One of: government_public_sector, media_entertainment, financial_services, healthcare_pharma, energy_utilities, retail_consumer, real_estate, agriculture_food, telecommunications, automotive, manufacturing_industrial, transport_logistics, aerospace_defense, mining_metals, construction_infrastructure, education, hospitality_travel, sports_recreation, nonprofit_ngo, legal_services, insurance, software_it_services, ecommerce, banking, defense_security, chemicals, fashion_apparel, gaming_esports, biotechnology, semiconductors, other_sector.
`api_key`	No	Optional NewsMCP API key for this call; forwarded upstream as x-api-key. Keyless: 7-day `from_` lookback, 20 calls/hour (shared per network address), 20 stories per call — over-limit requests are narrowed with a notice, not rejected. With a key the ceilings come from the plan (free tier today: 14 days, 50 calls/hour, 50 stories) and over-limit requests are rejected with a validation error instead of narrowed. Those per-plan numbers change without a release — call `check_limits` for the live values and the hourly budget left; it costs nothing. A keyed caller may have only one request in flight at a time, so never call in parallel.
`subject`	No	A single company, person, place, or organisation to centre the search on — plain name, no quoting. Quoted for you, which is the difference between a phrase and a bag of words: `Bank of America` unquoted ANDs three common terms and surfaces "Medtronic Revenue Grows" first, while the quoted phrase surfaces Bank of America. Combines with `q` (subject AND query), so `subject="Tesla", q="recall OR lawsuit"` reads as expected. Setting it also widens the default window from 24 hours to 30 days (clamped to the plan), because a company can go a fortnight without news — that is the single most common reason a name search comes back empty. Pass an explicit `from_` to override.
`event_id`	No	Superseded by the `get_story` tool, which does this with two arguments instead of nineteen and can return every source link. Kept for compatibility. Fetch ONE story directly by the `event_id` of an earlier result (e.g. `evt_...`) — use it for "pull that story up again". When set, every other filter is ignored. Stories are occasionally folded into a more complete story as coverage develops: that returns 404 naming the replacement id, so fetch that id instead. An id that never existed returns a plain not-found.
`verbosity`	No	Controls ONLY the source-link list; headline, summary, actors, and labels are always present. `compact`: no links. `standard` (default): up to 3. `full`: every link, uncapped — use it for "show me every source", but it makes a large `limit` very long.	standard
`event_type`	No	What KIND of event the story is, independent of industry. Exact `family.leaf` value; a bare family (`deals`) is invalid and unknown values are rejected naming them. Comma-separated for OR (`deals.merger_acquisition,funding.venture_funding_round` = "M&A or funding news"). The taxonomy is 59 leaves across 21 families, plus the standalone value `unclassifiable` for a labeled-but-uncategorizable story. Families: corporate_finance, markets, deals, governance, society_environment, sports, justice_crime, security, macro_policy, research_science, religion_society, politics, legal_regulatory, culture_media, product, accidents_disasters, operations, funding, local_civic, geopolitics, corporate_comms. The complete set of accepted values: corporate_finance.earnings_report, corporate_finance.analyst_rating, corporate_finance.dividends, markets.stock_move, markets.commodity_price, markets.currency_move, deals.merger_acquisition, deals.ipo_filing, deals.asset_sale, governance.board_change, governance.shareholder_vote, governance.executive_departure, society_environment.climate_event, society_environment.public_health, society_environment.environmental_incident, sports.match_result, sports.transfer_signing, sports.championship, justice_crime.arrest_charge, justice_crime.trial_verdict, justice_crime.investigation, security.cyberattack, security.data_breach, security.physical_security_incident, macro_policy.central_bank_decision, macro_policy.trade_policy, macro_policy.fiscal_policy, research_science.scientific_discovery, research_science.clinical_trial_result, research_science.publication, religion_society.religious_event, religion_society.social_movement, politics.election, politics.policy_announcement, politics.diplomacy, legal_regulatory.regulatory_action, legal_regulatory.lawsuit_filed, legal_regulatory.compliance_ruling, culture_media.celebrity_news, culture_media.entertainment_release, culture_media.award, product.product_launch, product.product_recall, product.feature_update, accidents_disasters.natural_disaster, accidents_disasters.industrial_accident, accidents_disasters.transport_accident, operations.plant_closure, operations.layoffs, operations.supply_chain_disruption, funding.venture_funding_round, funding.grant_award, local_civic.local_government_action, local_civic.infrastructure_project, geopolitics.armed_conflict, geopolitics.sanctions, geopolitics.diplomacy_summit, corporate_comms.press_release, corporate_comms.leadership_statement, unclassifiable.
`content_type`	No	The FORM the reporting takes, independent of what it is about. Comma-separated for OR. One of: news_report, press_release, service_info, human_interest, explainer, commentary, analysis, opinion, interview, obituary. There is no NOT on this field, so for "analysis, not straight news" name the forms wanted (`analysis`) rather than the ones to exclude.
`min_newsrooms`	No	Minimum outlets that reported INDEPENDENTLY, mirrors excluded — the strongest is-this-real signal. Reach for this over min_sources whenever the user wants to exclude a story that one outlet ran and everyone else reprinted. `3` ≈ "well-corroborated only".
`response_format`	No	Output shape in content[0].text. Default `markdown` (readable digest). `text` = plain lines. `json` = full API payload. Match what the user asks for.	markdown

Output Schema

ParametersJSON Schema

Name	Required	Description
`total`	No	Total matching stories; present for a search call.
`events`	No	Present for a search call (event_id unset).
`keyless_notices`	No	Present when a keyless caller's request was narrowed.

TDQS

A5/5.0

Behavior5/5

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

Annotations provide readOnlyHint and openWorldHint, but the description adds extensive behavioral detail: keyless vs. keyed limits, narrowing vs. rejection on over-limit, default windows and how subject widens them, the 404-with-replacement behavior for folded stories, the 'only one request in flight' constraint, and the semantics of each sort option. It goes far beyond what annotations offer and contains no contradictions.

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 long, but every sentence carries information an agent needs: limits, defaults, alternatives, and caveats. It is front-loaded with the core purpose and key facts, then organized by parameter with clear formatting (bold for emphasis, code for values). No fluff or redundancy; it is appropriately detailed for a tool with 13 parameters and many enums.

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 tool this complex, the description covers all necessary context: required vs. optional parameters, defaults, caps, how filters combine (AND/OR), when to widen the time window, how to handle over-limit responses, and where to get live limits (check_limits). It also clarifies that verbosity only affects the source-link list and that response_format controls the output shape. With an output schema present, the description is complete and self-sufficient.

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

Parameters5/5

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

Schema coverage is 100%, but the description adds substantial semantic value for every parameter: quoting rules for q, the difference between subject and q, the effect of limit on paging vs. hourly budget, the full taxonomy for event_type, and the meaning of min_newsrooms as an independence filter. It explains not just what each parameter is but how to use it effectively and common pitfalls.

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 opens with a clear, specific statement of what the tool does: 'Search already-synthesized news events — pre-built story digests — or fetch one by id.' It immediately distinguishes the tool from siblings by noting it works on pre-built digests and that fetching by id is superseded by get_story. The purpose is unambiguous and actionable.

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?

The description explicitly states use cases ('Use it for a quick digest... for deal/incident-type or industry filtering, and for corroboration ranking'), points to alternatives ('Call `check_limits` for the live numbers; it is free', and notes event_id is superseded by get_story). It also clarifies that a bare call returns the most-corroborated stories of the last 24 hours, giving a clear starting point. When to use vs. when not is well covered.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

3 tool updatesSep 17, 2026

Changedcheck_coverage1 field changed

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "additionalProperties": false,
+  "description": "Corroboration verdict for a claim.",
+  "properties": {
+    "anchor_newsrooms": {
+      "description": "Independent newsrooms for the best-corroborated matching story.",
+      "type": "integer"
+    },
+    "combined_newsrooms_upper_bound": {
+      "description": "Sum across clustered variants of the same story — an upper bound, not a confirmed count.",
+      "type": "integer"
+    },
+    "matched": {
+      "description": "Whether any story matched the claim text in the window.",
+      "type": "boolean"
+    },
+    "notes": {
+      "description": "Query-normalization and plan-clamping notes to relay verbatim.",
+      "items": {
+        "type": "string"
+      },
+      "type": "array"
+    },
+    "total_matching_stories": {
+      "type": "integer"
+    },
+    "variants": {
+      "description": "Anchor story first, then its likely variants.",
+      "items": {
+        "additionalProperties": true,
+        "properties": {
+          "abstract": {
+            "type": [
+              "string",
+              "null"
+            ]
+          },
+          "content_type": {
+            "type": [
+              "string",
+              "null"
+            ]
+          },
+          "entities": {
+            "description": "Key actors named in the story.",
+            "items": {
+              "additionalProperties": true,
+              "properties": {
+                "name": {
+                  "type": "string"
+                }
+              },
+              "type": "object"
+            },
+            "type": "array"
+          },
+          "event_id": {
+            "description": "Stable id, e.g. evt_...",
+            "type": "string"
+          },
+          "event_type": {
+            "description": "family.leaf taxonomy value, e.g. deals.merger_acquisition.",
+            "type": [
+              "string",
+              "null"
+            ]
+          },
+          "first_seen": {
+            "description": "ISO 8601 UTC.",
+            "type": [
+              "string",
+              "null"
+            ]
+          },
+          "headline": {
+            "type": [
+              "string",
+              "null"
+            ]
+          },
+          "language_count": {
+            "type": [
+              "integer",
+              "null"
+            ]
+          },
+          "last_seen": {
+            "description": "ISO 8601 UTC.",
+            "type": [
+              "string",
+              "null"
+            ]
+          },
+          "newsrooms": {
+            "description": "Independent newsrooms — the corroboration signal.",
+            "type": [
+              "integer",
+              "null"
+            ]
+          },
+          "one_liner": {
+            "type": [
+              "string",
+              "null"
+            ]
+          },
+          "reports": {
+            "type": [
+              "integer",
+              "null"
+            ]
+          },
+          "sector": {
+            "type": [
+              "string",
+              "null"
+            ]
+          },
+          "size": {
+            "description": "Article count.",
+            "type": [
+              "integer",
+              "null"
+            ]
+          },
+          "source_count": {
+            "description": "Publisher domains, mirrors included.",
+            "type": [
+              "integer",
+              "null"
+            ]
+          },
+          "sources": {
+            "description": "Source article URLs — a sample or the full list per verbosity.",
+            "items": {
+              "type": "string"
+            },
+            "type": "array"
+          }
+        },
+        "type": "object"
+      },
+      "type": "array"
+    }
+  },
+  "required": [
+    "matched",
+    "total_matching_stories",
+    "anchor_newsrooms",
+    "combined_newsrooms_upper_bound",
+    "variants",
+    "notes"
+  ],
+  "type": "object"
+}

Changedget_story1 field changed

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "additionalProperties": true,
+  "description": "One synthesized news event, expanded.",
+  "properties": {
+    "abstract": {
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "content_type": {
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "entities": {
+      "description": "Key actors named in the story.",
+      "items": {
+        "additionalProperties": true,
+        "properties": {
+          "name": {
+            "type": "string"
+          }
+        },
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "event_id": {
+      "description": "Stable id, e.g. evt_...",
+      "type": "string"
+    },
+    "event_type": {
+      "description": "family.leaf taxonomy value, e.g. deals.merger_acquisition.",
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "first_seen": {
+      "description": "ISO 8601 UTC.",
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "headline": {
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "language_count": {
+      "type": [
+        "integer",
+        "null"
+      ]
+    },
+    "last_seen": {
+      "description": "ISO 8601 UTC.",
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "newsrooms": {
+      "description": "Independent newsrooms — the corroboration signal.",
+      "type": [
+        "integer",
+        "null"
+      ]
+    },
+    "one_liner": {
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "reports": {
+      "type": [
+        "integer",
+        "null"
+      ]
+    },
+    "sector": {
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "size": {
+      "description": "Article count.",
+      "type": [
+        "integer",
+        "null"
+      ]
+    },
+    "source_count": {
+      "description": "Publisher domains, mirrors included.",
+      "type": [
+        "integer",
+        "null"
+      ]
+    },
+    "sources": {
+      "description": "Source article URLs — a sample or the full list per verbosity.",
+      "items": {
+        "type": "string"
+      },
+      "type": "array"
+    }
+  },
+  "type": "object"
+}

Changednews1 field changed

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "additionalProperties": true,
+  "allOf": [
+    {
+      "additionalProperties": true,
+      "properties": {
+        "abstract": {
+          "type": [
+            "string",
+            "null"
+          ]
+        },
+        "content_type": {
+          "type": [
+            "string",
+            "null"
+          ]
+        },
+        "entities": {
+          "description": "Key actors named in the story.",
+          "items": {
+            "additionalProperties": true,
+            "properties": {
+              "name": {
+                "type": "string"
+              }
+            },
+            "type": "object"
+          },
+          "type": "array"
+        },
+        "event_id": {
+          "description": "Stable id, e.g. evt_...",
+          "type": "string"
+        },
+        "event_type": {
+          "description": "family.leaf taxonomy value, e.g. deals.merger_acquisition.",
+          "type": [
+            "string",
+            "null"
+          ]
+        },
+        "first_seen": {
+          "description": "ISO 8601 UTC.",
+          "type": [
+            "string",
+            "null"
+          ]
+        },
+        "headline": {
+          "type": [
+            "string",
+            "null"
+          ]
+        },
+        "language_count": {
+          "type": [
+            "integer",
+            "null"
+          ]
+        },
+        "last_seen": {
+          "description": "ISO 8601 UTC.",
+          "type": [
+            "string",
+            "null"
+          ]
+        },
+        "newsrooms": {
+          "description": "Independent newsrooms — the corroboration signal.",
+          "type": [
+            "integer",
+            "null"
+          ]
+        },
+        "one_liner": {
+          "type": [
+            "string",
+            "null"
+          ]
+        },
+        "reports": {
+          "type": [
+            "integer",
+            "null"
+          ]
+        },
+        "sector": {
+          "type": [
+            "string",
+            "null"
+          ]
+        },
+        "size": {
+          "description": "Article count.",
+          "type": [
+            "integer",
+            "null"
+          ]
+        },
+        "source_count": {
+          "description": "Publisher domains, mirrors included.",
+          "type": [
+            "integer",
+            "null"
+          ]
+        },
+        "sources": {
+          "description": "Source article URLs — a sample or the full list per verbosity.",
+          "items": {
+            "type": "string"
+          },
+          "type": "array"
+        }
+      },
+      "type": "object"
+    }
+  ],
+  "description": "A page of synthesized news events for a search call, or — when `event_id` is set — a single event's own fields at the top level instead of under `events`.",
+  "properties": {
+    "events": {
+      "description": "Present for a search call (event_id unset).",
+      "items": {
+        "additionalProperties": true,
+        "properties": {
+          "abstract": {
+            "type": [
+              "string",
+              "null"
+            ]
+          },
+          "content_type": {
+            "type": [
+              "string",
+              "null"
+            ]
+          },
+          "entities": {
+            "description": "Key actors named in the story.",
+            "items": {
+              "additionalProperties": true,
+              "properties": {
+                "name": {
+                  "type": "string"
+                }
+              },
+              "type": "object"
+            },
+            "type": "array"
+          },
+          "event_id": {
+            "description": "Stable id, e.g. evt_...",
+            "type": "string"
+          },
+          "event_type": {
+            "description": "family.leaf taxonomy value, e.g. deals.merger_acquisition.",
+            "type": [
+              "string",
+              "null"
+            ]
+          },
+          "first_seen": {
+            "description": "ISO 8601 UTC.",
+            "type": [
+              "string",
+              "null"
+            ]
+          },
+          "headline": {
+            "type": [
+              "string",
+              "null"
+            ]
+          },
+          "language_count": {
+            "type": [
+              "integer",
+              "null"
+            ]
+          },
+          "last_seen": {
+            "description": "ISO 8601 UTC.",
+            "type": [
+              "string",
+              "null"
+            ]
+          },
+          "newsrooms": {
+            "description": "Independent newsrooms — the corroboration signal.",
+            "type": [
+              "integer",
+              "null"
+            ]
+          },
+          "one_liner": {
+            "type": [
+              "string",
+              "null"
+            ]
+          },
+          "reports": {
+            "type": [
+              "integer",
+              "null"
+            ]
+          },
+          "sector": {
+            "type": [
+              "string",
+              "null"
+            ]
+          },
+          "size": {
+            "description": "Article count.",
+            "type": [
+              "integer",
+              "null"
+            ]
+          },
+          "source_count": {
+            "description": "Publisher domains, mirrors included.",
+            "type": [
+              "integer",
+              "null"
+            ]
+          },
+          "sources": {
+            "description": "Source article URLs — a sample or the full list per verbosity.",
+            "items": {
+              "type": "string"
+            },
+            "type": "array"
+          }
+        },
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "keyless_notices": {
+      "description": "Present when a keyless caller's request was narrowed.",
+      "items": {
+        "type": "string"
+      },
+      "type": "array"
+    },
+    "total": {
+      "description": "Total matching stories; present for a search call.",
+      "type": "integer"
+    }
+  },
+  "type": "object"
+}

5 tool updatesSep 6, 2026
- First observedcheck_coverage
- First observedcheck_health
- First observedcheck_limits
- First observedget_story
- First observednews

Related MCP Connectors

Geotone — Global News Signals A
news.geotone
Live global news signals: ranked wire, story timelines, coverage volume/tone/surges. Free, no auth.
Search Research & Data
82
newsflash A
sh.newsflash
Real-time corroborated news events + 5-year archive, for agents. Free tier, no key.
Search Open Data
52
news-mcp-server A
com.thenextgennexus
Cross-source news (AP, BBC, NPR, HN, Google News) with topic filtering and dedup.
Search
52
Real-Time News A
org.memoryapi
Real-time news and trending topics from major sources
Search Browser Automation Web Scraping
2

Related MCP Servers

NewsMCP — World news for AI
pranciskus
A
license
Not graded
quality
C
maintenance
Real-time news events, clustered by AI from hundreds of sources, classified by topic and geography, ranked by importance.
Updated 7 months ago (2026-03-06 15:24 UTC)
35
MIT
typesearch-mcpofficial
Search Research & Data
typesearch-ai
A
license
Not graded
quality
C
maintenance
Enables AI agents to search recent news worldwide by topic, country, and language, offering ranked results with relevance scores, article excerpts, content retrieval, similar-story discovery, and coverage checks.
Updated a day ago (2026-09-26 02:41 UTC)
MIT
Newsline MCP Server
Open Data Research & Data Search
nulljosh
A
license
Not graded
quality
A
maintenance
Provides current headlines from 17 news outlets across the political spectrum with bias tags and blindspot detection for stories covered by only one side.
Updated 21 hours ago (2026-09-26 05:58 UTC)
MIT
Google Trends MCP Server
Search Web Scraping Browser Automation
yusuf-polat
A
license
Not graded
quality
C
maintenance
Provides real-time trending topics, news headlines, article summaries, and full-text extraction for AI assistants across 250+ countries and categories.
Updated 9 days ago (2026-09-17 15:29 UTC)
66 npm
1
ISC