A
licenseNot graded
qualityD
maintenanceReal-time news events, clustered by AI from hundreds of sources, classified by topic and geography, ranked by importance.
35
MIT
NewsMCP
by com.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 by verifying the domain or GitHub account it belongs to. Claimed connector authors can inspect health checks, view analytics, and manage their listing.
- Status
- Healthy
- Uptime
- 99.5% over 62 days
- Last Tested
- Transport
- Streamable HTTP · MCP 2025-11-25
- URL
- ChatGPT
- –
- Claude
- NewsMCP without a key
TDQS
A4.3/5.0
Scored across 5 tools
Disambiguation4/5
Each tool has a largely distinct role: health, quota, story expansion, search, and coverage judgment. However, `news` explicitly claims it can 'fetch one by id' and offers 'corroboration ranking', which overlaps with `get_story` (expand by id) and `check_coverage` (is this real?) — the descriptions clarify the split, but an agent could still misselect between them.
Naming Consistency4/5
Four of five tools follow a clean verb_noun pattern (check_coverage, check_health, check_limits, get_story). The outlier `news` is a bare noun that also does searching, a minor break in an otherwise predictable scheme.
Tool Count5/5
Five tools is a tight, well-scoped surface for a news search API: search, expand, verify, plus two operational probes. No tool looks redundant or bolted on.
Completeness4/5
The core loop — search, drill into a story with sources, assess corroboration, and manage quota — is fully covered with no dead ends. Minor gaps remain: no way to enumerate available sectors/event types before filtering, and no source/outlet-level lookup beyond a single story's source list.
Available Tools
5 toolscheck_coverageARead-onlyInspect
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.
| 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. | |
| 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
| 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.3/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only cover the safety profile (readOnly, openWorld, non-destructive), so the description carries the real weight here — it explains the independent-newsroom versus carrying-domain distinction with a concrete example, and discloses that cross-language clustering makes the reported total an upper bound with the combined variants listed for verification. That is exactly the kind of interpretive caveat an agent needs to report the number honestly. It does not say what happens on a zero-match claim or discuss latency/cost, which keeps it from a 5.
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?
Front-loaded with the purpose in the first sentence, then two paragraphs that each add a distinct layer: what it reports and why the independence count matters, then the cross-language aggregation caveat. The '200 domains from 3 newsrooms' illustration earns its place by making the core metric concrete.
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 an output schema present, the description needn't enumerate return values, and it correctly spends its budget on the interpretive semantics of the result instead. For a three-parameter read-only check, nothing an agent needs in order to call it correctly or describe its output is missing.
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 coverage is 100%, with claim, days_back, and response_format each documented in detail (including the literal-matching caveat and plan clamping), so the schema already does the heavy lifting. The description adds no parameter-level meaning beyond that, which is the correct baseline of 3 when the schema is this complete.
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 — judging how widely and independently a claim has been reported — and immediately distinguishes the output type from its siblings with "Answers 'is this real?' rather than returning a list." An agent can tell this apart from news and get_story 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?
The phrase "rather than returning a list" clearly signals this is a verdict tool, not a browsing tool, which implicitly routes callers away from the list-returning siblings. It stops short of naming news or get_story explicitly, or stating the when-not case (e.g. if you want to read the articles themselves, use get_story).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
check_healthARead-onlyInspect
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.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output 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_limitsARead-onlyInspect
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.
| Name | Required | Description | Default |
|---|---|---|---|
| response_format | No | `text` (default) for a readable summary, `json` for the raw payload. | text |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
A4.7/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only declare the safe read profile; the description adds the operationally decisive facts an agent cannot infer: the endpoint is exempt from every metering stage, so it consumes no hourly call, concurrency slot, or credit. It further discloses that ceilings are per-plan and change without a release, which explains why the values are authoritative and volatile.
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 core claim is front-loaded in the first clause, followed by three short paragraphs that each carry distinct information: what is answered, what it costs, and when to call it. No sentence restates the schema or the annotations, and the rhetorical opener still conveys the key property (non-metered introspection).
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 is simple (zero required params) and an output schema exists, so return values need no prose explanation. What an agent still needs in order to call it well — cost model, volatility of the ceilings, and error-recovery usage — is all present.
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?
There is a single optional `response_format` parameter and the schema already documents both enum values at 100% coverage, so the schema carries the full burden. The description adds no syntax or format guidance beyond that, which is the baseline case rather than a gap.
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 — reporting the caller's current entitlements — and enumerates exactly what is reported: remaining searches this hour, plan history depth, max `limit`, concurrency, and retry wait. It explicitly positions itself against siblings by saying it answers what the `news` tool descriptions cannot, so an agent can distinguish it from `check_coverage`, `check_health`, and `get_story` without opening a schema.
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?
It gives two concrete trigger conditions — before planning a batch of calls, and after any plan-limit or rate-limit error — and explicitly says to prefer it over numbers hard-coded in other tool descriptions. That is a named alternative plus the condition that selects it, which is the routing guidance the dimension asks for.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_storyARead-onlyInspect
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.
| Name | Required | Description | Default |
|---|---|---|---|
| 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
| 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
A4.1/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=true, so safety is covered. The description adds genuinely new behavioral context: this is the only route to a complete source list because search endpoints cap it, and that source volume can reach several hundred links.
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?
Three short sentences with the core action front-loaded and the usage cue immediately after. The 'only place the complete list is available' claim is repeated between prose and schema, which is mild duplication rather than harmful, but it does cost a bit of tightness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, return-value detail is unnecessary, and the description still covers the expansion scope, the source-list caveat, and the post-search workflow. Nothing essential for correct invocation is missing, though naming the search sibling would have closed the last gap.
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 all three parameters are already documented in the schema, including the include_sources trade-off and the 404-replacement behavior for event_id. The description adds nothing beyond what the schema states, so the baseline of 3 applies.
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 ('Expand one story') and enumerates what comes back: full summary, classification, actors, source links. It also claims a unique capability ('the only tool that can return a story's complete source list'), which separates it from news and the check_* siblings.
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?
'Use this after any search, when the user wants more than the digest line for a particular story' gives a clear trigger and sequencing. It stops short of naming the sibling to use for the initial search (news) or stating when not to call it, so it is not a full when/when-not/alternatives statement.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
newsARead-onlyInspect
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.
| 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. | |
| 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
| 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
A4.6/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnly/openWorld/non-destructive annotations, it discloses keyless vs keyed quotas, that over-limit is narrowed keyless but rejected with a key, the 7/14-day lookback ceiling, and that folded stories return a 404 naming a replacement id. That is exactly the behavioral context annotations cannot express.
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 output shape are front-loaded, then defaults, limits, and filter-combination rules in descending importance. The limits paragraph partially restates what the schema repeats per-parameter, which is the only measurable waste.
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 12 optional parameters, an output schema, and 100% schema coverage, the description supplies the remaining pieces — default behavior on an empty call, quota semantics, error shapes, and lookback ceilings. Nothing material for correct invocation 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 description coverage is 100%, so the baseline is 3; the description still adds meaning by stating that filters combine with AND on event_type/content_type/sector and that omitted filters yield a next-24h corroboration-ranked digest. It does not re-explain individual parameter syntax, which the schema already handles well.
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 names a specific verb and resource — search pre-built story digests — and immediately scopes it to synthesized (not raw) news, with a secondary fetch-by-id mode. An agent can distinguish this from get_story and the check_* siblings without opening a 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 gives concrete use cases (quick digest, deal/incident or industry filtering, corroboration ranking), states that a bare call returns the most-corroborated last-24h stories, and routes to `check_limits` for live caps and to `get_story` for single-story retrieval. It stops short of an explicit 'do not use this when…' exclusion, so it lands just under a 5.
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.
5 tool updates
- Changed
check_coverage2 fields changed- removed
Input schema / properties / api_keyRemoved value: -{ - "anyOf": [ - { - "type": "string" - }, - { - "type": "null" - } - ], - "default": null, - "description": "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." -} - removed
Input schema / properties / llm_modelRemoved value: -{ - "description": "The exact model identifier you (the assistant) are running as, taken from your system prompt or environment (e.g. \"claude-opus-4-8\", \"gpt-5.2\"). Used for analytics only. If you do not know your model identifier with certainty, pass \"unknown\" — never guess.", - "type": "string" -}
- Changed
check_health1 field changed- removed
Input schema / properties / llm_modelRemoved value: -{ - "description": "The exact model identifier you (the assistant) are running as, taken from your system prompt or environment (e.g. \"claude-opus-4-8\", \"gpt-5.2\"). Used for analytics only. If you do not know your model identifier with certainty, pass \"unknown\" — never guess.", - "type": "string" -}
- Changed
check_limits2 fields changed- removed
Input schema / properties / api_keyRemoved value: -{ - "anyOf": [ - { - "type": "string" - }, - { - "type": "null" - } - ], - "default": null, - "description": "Optional NewsMCP API key. Report the ceilings for this key's plan; omit to report the keyless ceilings." -} - removed
Input schema / properties / llm_modelRemoved value: -{ - "description": "The exact model identifier you (the assistant) are running as, taken from your system prompt or environment (e.g. \"claude-opus-4-8\", \"gpt-5.2\"). Used for analytics only. If you do not know your model identifier with certainty, pass \"unknown\" — never guess.", - "type": "string" -}
- Changed
get_story2 fields changed- removed
Input schema / properties / api_keyRemoved value: -{ - "anyOf": [ - { - "type": "string" - }, - { - "type": "null" - } - ], - "default": null, - "description": "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." -} - removed
Input schema / properties / llm_modelRemoved value: -{ - "description": "The exact model identifier you (the assistant) are running as, taken from your system prompt or environment (e.g. \"claude-opus-4-8\", \"gpt-5.2\"). Used for analytics only. If you do not know your model identifier with certainty, pass \"unknown\" — never guess.", - "type": "string" -}
- Changed
news2 fields changed- removed
Input schema / properties / api_keyRemoved value: -{ - "anyOf": [ - { - "type": "string" - }, - { - "type": "null" - } - ], - "default": null, - "description": "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." -} - removed
Input schema / properties / llm_modelRemoved value: -{ - "description": "The exact model identifier you (the assistant) are running as, taken from your system prompt or environment (e.g. \"claude-opus-4-8\", \"gpt-5.2\"). Used for analytics only. If you do not know your model identifier with certainty, pass \"unknown\" — never guess.", - "type": "string" -}
5 tool updates
- Changed
check_coverage1 field changed- added
Input schema / properties / llm_modelAdded value: +{ + "description": "The exact model identifier you (the assistant) are running as, taken from your system prompt or environment (e.g. \"claude-opus-4-8\", \"gpt-5.2\"). Used for analytics only. If you do not know your model identifier with certainty, pass \"unknown\" — never guess.", + "type": "string" +}
- Changed
check_health1 field changed- added
Input schema / properties / llm_modelAdded value: +{ + "description": "The exact model identifier you (the assistant) are running as, taken from your system prompt or environment (e.g. \"claude-opus-4-8\", \"gpt-5.2\"). Used for analytics only. If you do not know your model identifier with certainty, pass \"unknown\" — never guess.", + "type": "string" +}
- Changed
check_limits1 field changed- added
Input schema / properties / llm_modelAdded value: +{ + "description": "The exact model identifier you (the assistant) are running as, taken from your system prompt or environment (e.g. \"claude-opus-4-8\", \"gpt-5.2\"). Used for analytics only. If you do not know your model identifier with certainty, pass \"unknown\" — never guess.", + "type": "string" +}
- Changed
get_story1 field changed- added
Input schema / properties / llm_modelAdded value: +{ + "description": "The exact model identifier you (the assistant) are running as, taken from your system prompt or environment (e.g. \"claude-opus-4-8\", \"gpt-5.2\"). Used for analytics only. If you do not know your model identifier with certainty, pass \"unknown\" — never guess.", + "type": "string" +}
- Changed
news1 field changed- added
Input schema / properties / llm_modelAdded value: +{ + "description": "The exact model identifier you (the assistant) are running as, taken from your system prompt or environment (e.g. \"claude-opus-4-8\", \"gpt-5.2\"). Used for analytics only. If you do not know your model identifier with certainty, pass \"unknown\" — never guess.", + "type": "string" +}
3 tool updates
- Changed
check_coverage1 field changed- changed
Output 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" +}
- Changed
get_story1 field changed- changed
Output 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" +}
- Changed
news1 field changed- changed
Output 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 updates
- First observed
check_coverage - First observed
check_health - First observed
check_limits - First observed
get_story - First observed
news
Related MCP Connectors
Live global news signals: ranked wire, story timelines, coverage volume/tone/surges. Free, no auth.
The world's news on a live map: place briefings, storylines, statistics, live layers, businesses.
Geo-tagged world news for agents: each story split into viewpoints, with support counts.
Real-time corroborated news events + 5-year archive, for agents. Free tier, no key.
Related MCP Servers
typesearch-mcpofficial
AlicenseNot gradedqualityCmaintenanceEnables 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.1MIT- AlicenseNot gradedqualityAmaintenanceProvides current headlines from 17 news outlets across the political spectrum with bias tags and blindspot detection for stories covered by only one side.MIT
- AlicenseNot gradedqualityCmaintenanceProvides real-time trending topics, news headlines, article summaries, and full-text extraction for AI assistants across 250+ countries and categories.152 npm1ISC
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.