-
licenseNot graded
qualityNot graded
maintenanceA remote MCP server that enables searching for news articles on specific topics through the Tavily API without requiring authentication.
-
news-checker-mcp
by n40yuk1
Fetches the latest technology news from Ars Technica, including article previews and full content.
Aggregates top headlines and news stories from Google News across multiple categories such as world and business.
Provides access to the latest science and space news from NASA, including article summaries and full texts.
Retrieves recent technology and startup news from TechCrunch, with support for reading full articles.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@news-checker-mcplatest tech news"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
📰 News Checker MCP Server
世界中のニュースソースから最新ニュースを取得するMCPサーバーです。
APIキー不要。ジャンル指定対応。
提供ツール
ツール名 | 説明 |
| 最新ニュースを取得（カテゴリ指定可、デフォルトは世界の主要ニュース横断） |
| 記事URLを指定して本文を取得 |
| 利用可能なカテゴリ一覧 |
Related MCP server: gnews-mcp-server
カテゴリ & ニュースソース
カテゴリ | ソース |
| BBC, Reuters, Al Jazeera, AP, NHK World, Google News |
| TechCrunch, The Verge, Ars Technica, Hacker News |
| CNBC, Bloomberg, Google News |
| Nature, Science Daily, NASA |
| ESPN, BBC Sport |
| Variety, Hollywood Reporter |
| Yahoo!ニュース, NHK, はてなブックマーク |
セットアップ
npm install
npm run buildMCP クライアント設定
{
"mcpServers": {
"news-checker": {
"command": "node",
"args": ["C:/Users/n40yu/Documents/docker/openclaw/news-checker-mcp/dist/index.js"]
}
}
}使い方の例
聞き方 | 動作 |
「最新ニュースを教えて」 |
|
「テクノロジーのニュースは？」 |
|
「スポーツニュースチェックして」 |
|
「この記事の詳細を読んで」 |
|
Available Tools
3 toolscheck_newsB
最新ニュースを取得します。ジャンルを指定して世界中のニュースソースから最新記事を一覧表示。デフォルトでは世界の主要ニュースを横断的に取得します。
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| count | No | 取得件数 (1-50) | |
| category | No | ニュースカテゴリ: world(世界), tech(テクノロジー), business(ビジネス), science(科学), sports(スポーツ), entertainment(エンタメ), japan(日本)。省略時は複数カテゴリ横断 |
TDQS
B3.3/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Only states it retrieves and lists articles; lacks disclosure on rate limits, pagination, data freshness, or return format.
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, clear sentences with efficient wording. No fluff, front-loaded with the main action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequate for a simple tool with 2 parameters and no output schema, but missing details on return structure and error handling. Could be more complete for agent invocation.
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 descriptions for both parameters. Description adds minor context (default cross-cutting world news) but does not significantly extend beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it fetches latest news and can specify a genre. It distinguishes from siblings (list_categories, read_article) by focusing on news articles as opposed to categories or individual article reading, but does not explicitly differentiate.
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?
Implies usage by mentioning genre specification and default broad coverage, but no explicit when-to-use, when-not-to-use, or comparison with alternatives like list_categories.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_categoriesA
利用可能なニュースカテゴリの一覧を表示します。
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
TDQS
A3.7/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It only says 'displays a list' without disclosing whether it's read-only, authentication needs, or what the list contains beyond being categories.
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?
Single sentence, no extraneous information. Efficiently conveys the essential purpose.
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?
Given zero parameters, no output schema, and simple functionality, the description is complete enough. The agent can correctly infer usage without additional detail.
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?
There are no parameters, and schema coverage is 100% trivially. The description adds no param details but none are needed; baseline 4 is appropriate.
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 displays a list of available news categories, with a specific verb and resource. Sibling tools check_news and read_article suggest different actions, so this tool is distinctive.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus siblings. It does not provide context, prerequisites, or exclusions, leaving the agent to infer appropriate usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
read_articleA
ニュース記事のURLを指定して本文を取得します。check_newsで見つけた記事の詳細を読むのに使います。
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | 読みたい記事のURL |
TDQS
A4.3/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries burden. It implies read-only via '取得' but does not explicitly state safety properties or potential issues like invalid URL handling. Adequate but not rich.
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 sentences, front-loaded with action and usage context, no wasted words.
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 simple read tool with one parameter and no output schema, the description provides sufficient context including reference to sibling tool 'check_news'.
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% and schema description already explains the parameter. The tool description does not add new information beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool fetches the body of a news article given a URL, and distinguishes it from sibling 'check_news' by stating it is used to read details of articles found there.
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 says to use this tool after finding articles with 'check_news', providing clear usage context and differentiation.
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 updates
v1.0.0- First observed
check_news - First observed
list_categories - First observed
read_article
TDQS
A3.9/5.0
Scored across 3 tools
Disambiguation5/5
Each tool serves a distinct purpose: check_news fetches articles, list_categories provides categories, and read_article retrieves full content. There is no overlap or ambiguity.
Naming Consistency5/5
All tool names follow a consistent verb_noun pattern in snake_case (check_news, list_categories, read_article), making the set predictable and easy to understand.
Tool Count4/5
With only 3 tools, the set is minimal but appropriate for a basic news checking server—covering fetching, category listing, and article reading. It could be expanded with search or filtering, but the count is not inappropriate.
Completeness4/5
The tool set covers the core workflow (fetch, categorize, read). Missing advanced features like keyword search or date filtering, but for a simple news checker, it is reasonably complete.
Maintenance
ActivityInactive
ResponsivenessNo issues
Related MCP Connectors
News MCP: real-time headlines & custom news search across 7 regions. Free, just sign in with Google.
News MCP: real-time headlines & custom news search across 7 regions. Free, just sign in with Google.
GNews MCP — Global news search via GNews API (gnews.io)
Related MCP Servers
- FlicenseNot gradedqualityFmaintenanceMCP server providing access to the GNews API for fetching news articles and headlines. Supports search and top headlines with advanced filtering by language, country, category, and date.1-
- AlicenseBqualityDmaintenanceA Model Context Protocol (MCP) server that provides access to global news articles through the News API. It implements a standardized interface for searching news articles, retrieving top headlines, and listing available news sources.312MIT
- AlicenseNot gradedqualityCmaintenanceSearch, trending, topics, and local news all in one MCP server. Article previews, deduplication, source filtering, and 40+ languages built in.28 npm2MIT