Which integrations are available for this server?

The server is distributed as a Python package on PyPI under the name 'bach-news_api14', allowing installation via pip.

How do I use News Api14 MCP Server?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@News Api14 MCP Server search for latest technology news in English from the past week" 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 Api14 MCP Server

by BACH-AI-Tools

Overview Schema Related Servers Score Discussions

Python

Remote

News Api14 MCP Server

English | 简体中文 | 繁體中文

用于访问 News Api14 API 的 MCP 服务器。

🚀 使用 EMCP 平台快速体验

EMCP 是一个强大的 MCP 服务器管理平台，让您无需手动配置即可快速使用各种 MCP 服务器！

快速开始：

🌐 访问 EMCP 平台
📝 注册并登录账号
🎯 进入 MCP 广场，浏览所有可用的 MCP 服务器
🔍 搜索或找到本服务器（bach-news_api14）
🎉 点击 "安装 MCP" 按钮
✅ 完成！即可在您的应用中使用

EMCP 平台优势：

✨ 零配置：无需手动编辑配置文件
🎨 可视化管理：图形界面轻松管理所有 MCP 服务器
🔐 安全可靠：统一管理 API 密钥和认证信息
🚀 一键安装：MCP 广场提供丰富的服务器选择
📊 使用统计：实时查看服务调用情况

立即访问 EMCP 平台 开始您的 MCP 之旅！

Related MCP server: GNews MCP Server

简介

这是一个 MCP 服务器，用于访问 News Api14 API。

PyPI 包名: bach-news_api14
版本: 1.0.0
传输协议: stdio

安装

从 PyPI 安装:

pip install bach-news_api14

从源码安装:

pip install -e .

运行

方式 1: 使用 uvx（推荐，无需安装）

# 运行（uvx 会自动安装并运行）
uvx --from bach-news_api14 bach_news_api14

# 或指定版本
uvx --from bach-news_api14@latest bach_news_api14

方式 2: 直接运行（开发模式）

python server.py

方式 3: 安装后作为命令运行

# 安装
pip install bach-news_api14

# 运行（命令名使用下划线）
bach_news_api14

配置

API 认证

此 API 需要认证。请设置环境变量:

export API_KEY="your_api_key_here"

环境变量

变量名	说明	必需
`API_KEY`	API 密钥	是
`PORT`	不适用	否
`HOST`	不适用	否

在 Cursor 中使用

编辑 Cursor MCP 配置文件 ~/.cursor/mcp.json:

{
  "mcpServers": {
    "bach-news_api14": {
      "command": "uvx",
      "args": ["--from", "bach-news_api14", "bach_news_api14"],
      "env": {
        "API_KEY": "your_api_key_here"
      }
    }
  }
}

在 Claude Desktop 中使用

编辑 Claude Desktop 配置文件 claude_desktop_config.json:

{
  "mcpServers": {
    "bach-news_api14": {
      "command": "uvx",
      "args": ["--from", "bach-news_api14", "bach_news_api14"],
      "env": {
        "API_KEY": "your_api_key_here"
      }
    }
  }
}

可用工具

此服务器提供以下工具:

`search_publishers`

Find a list of publishers with details like descriptions, logos, languages, categories, and links to their social media.

端点: GET /v2/search/publishers

参数:

query (string) 必需: Just type what you're looking for.
country (string): 2-letter ISO 3166-1 code of the country.
language (string): 2-letter ISO 3166-1 code of the language.
category (string): Possible options: general, business, entertainment, lifestyle, politics, science, sports, technology.
sort (string): Possible options: popularity, relevancy.

`get_article_content`

This API endpoint provides access to the comprehensive metadata and content of a specific article.

端点: GET /v2/article

参数:

url (string) 必需: The URL of the article.
type (string): The article content output type can be specified as eitherhtml or plaintext. The default output type is plaintext. Note: The content is accessible only to users who have a valid subscription plan.

`search_articles`

Find articles by keywords and allows you to filter by country, language, publisher, and date to get specific result.

端点: GET /v2/search/articles

参数:

query (string) 必需: Just type what you're looking for, like cats or weather. If you want to exclude term, just add minus (-) in front of any term (nasa -moon).
language (string) 必需: example: en, fr, de, zh-Hant. Check out the Supported Languages endpoint to see a list of all the languages you can search for.
publisher (string): A domain of the news source. Example: cnn.com
from (string): Accepts human-readable formats like 1d for 1 day, 1m for 1 month, 1y for 1 year, as well as ISO 8601, RFC 2822, and Unix timestamp formats.
to (string): Accepts human-readable formats like 1d for 1 day, 1m for 1 month, 1y for 1 year, as well as ISO 8601, RFC 2822, and Unix timestamp formats.
limit (number): This parameter controls the maximum number of articles returned on a single page.
page (number): This parameter specifies the page number you want to access. For example, page=2 will return the second page of results.

`get_random_article`

This endpoint gives you the ability to find new and engaging content by randomly selecting an article, with the option to filter by country or language.

端点: GET /v2/article/random

参数:

language (string): example: en, fr, de, zh-Hant. Check out the Supported Languages endpoint to see a list of all the languages you can search for.
topic (string): The topic of interest, example: General, Politics, Sports, or a subtopic Soccer. Check out the Supported Topics endpoint to see a list of all the topics you can search for.
type (string): The article content output type can be specified as eitherhtml or plaintext. The default output type is plaintext. Note: The content is accessible only to users who have a valid subscription plan.

`trending_topics`

This endpoint lets you find the most popular news article for a specific country, language, and topic (like sports or entertainment).

端点: GET /v2/trendings

参数:

date (string): Example value:
topic (string) 必需: The topic of interest, example: General, Politics, Sports, or a subtopic Soccer. Check out the Supported Topics endpoint to see a list of all the topics you can search for.
language (string) 必需: example: en, fr, de, zh-Hant. Check out the Supported Languages endpoint to see a list of all the languages you can search for.
country (string): example: us, in, fr, de, id . Check out the Supported Countries endpoint to see a list of all the countries you can search for.
limit (number): This parameter controls the maximum number of articles returned on a single page.
page (number): This parameter specifies the page number you want to access. For example, page=2 will return the second page of results.

`supported_countries`

This endpoint provides a list of supported countries along with their respective languages.

端点: GET /v2/info/countries

`supported_languages`

This endpoint provides a list of supported languages.

端点: GET /v2/info/languages

`supported_topics`

This endpoint provides information about the supported topics. Access to the specific topics may be restricted based on your subscription plan.

端点: GET /v2/info/topics

技术栈

传输协议: stdio
HTTP 客户端: httpx

许可证

MIT License - 详见 LICENSE 文件。

开发

此服务器由 API-to-MCP 工具生成。

版本: 1.0.0

Available Tools

8 tools

get_article_contentC

This API endpoint provides access to the comprehensive metadata and content of a specific article.

ParametersJSON Schema

Name	Required	Description	Default
`url`	Yes	The URL of the article.
`type`	No	The article content output type can be specified as eitherhtml or plaintext. The default output type is plaintext. Note: The content is accessible only to users who have a valid subscription plan.

TDQS

C2.9/5.0

Behavior2/5

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

No annotations are provided, and the description does not disclose behavioral traits such as authentication requirements, rate limits, or error handling. The subscription note is in the schema, not the description.

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?

The description is a single sentence and concise. However, it could be slightly improved by removing redundant phrasing like 'API endpoint'.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the lack of output schema and annotations, the description should provide more context about what 'comprehensive metadata' includes or the structure of the response. It is incomplete for an agent to fully understand the tool's output.

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%, so the schema already explains both parameters. The description adds no extra meaning beyond stating that the tool provides metadata and content.

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?

The description clearly states the tool accesses metadata and content of a specific article, but it does not explicitly differentiate from sibling tools like get_random_article which also returns article content.

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?

The description provides no guidance on when to use this tool versus alternatives such as search_articles or get_random_article. There is no mention of prerequisites or exclusions.

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

get_random_articleC

This endpoint gives you the ability to find new and engaging content by randomly selecting an article, with the option to filter by country or language.

ParametersJSON Schema

Name	Required	Description
`language`	No	example: en, fr, de, zh-Hant. Check out the Supported Languages endpoint to see a list of all the languages you can search for.
`topic`	No	The topic of interest, example: General, Politics, Sports, or a subtopic Soccer. Check out the Supported Topics endpoint to see a list of all the topics you can search for.
`type`	No	The article content output type can be specified as eitherhtml or plaintext. The default output type is plaintext. Note: The content is accessible only to users who have a valid subscription plan.

TDQS

C2.5/5.0

Behavior2/5

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

With no annotations, the description bears the full burden of behavioral disclosure. It mentions random selection and optional filtering but omits critical details: authentication requirements for content, the fact that 'type' controls output format and content availability, and what the return value (article metadata vs. full content) contains.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence, which is concise but lacks structure. It could be improved by separating purpose, parameters, and behavior into a more organized format. It is not overly verbose, but too brief for the tool's complexity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given three parameters, no output schema, and no annotations, the description is incomplete. It omits authentication prerequisites, output details, and the filter mismatch reduces completeness. A more thorough description is needed for an agent to use the tool effectively.

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 adequate descriptions for each parameter. The description adds no extra meaning, and it misidentifies one filter ('country' instead of 'topic'). Baseline score of 3 is appropriate since the schema already documents parameters sufficiently.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose3/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states that it randomly selects an article with optional filters, which differentiates it from sibling tools like search_articles. However, it inaccurately mentions filtering by 'country' when the schema contains language, topic, and type, causing confusion about what filters are available.

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 is provided on when to use this tool versus alternatives such as search_articles or get_article_content. The description does not specify the ideal use case (e.g., discovery) or exclude scenarios where other tools are more appropriate.

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

search_articlesB

Find articles by keywords and allows you to filter by country, language, publisher, and date to get specific result.

ParametersJSON Schema

Name	Required	Description	Default
`query`	Yes	Just type what you're looking for, like cats or weather. If you want to exclude term, just add minus (-) in front of any term (nasa -moon).
`language`	Yes	example: en, fr, de, zh-Hant. Check out the Supported Languages endpoint to see a list of all the languages you can search for.
`publisher`	No	A domain of the news source. Example: cnn.com
`from`	No	Accepts human-readable formats like 1d for 1 day, 1m for 1 month, 1y for 1 year, as well as ISO 8601, RFC 2822, and Unix timestamp formats.
`to`	No	Accepts human-readable formats like 1d for 1 day, 1m for 1 month, 1y for 1 year, as well as ISO 8601, RFC 2822, and Unix timestamp formats.
`limit`	No	This parameter controls the maximum number of articles returned on a single page.	0
`page`	No	This parameter specifies the page number you want to access. For example, page=2 will return the second page of results.	0

TDQS

B3.4/5.0

Behavior2/5

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

No annotations provided, so description must disclose behavioral traits. It only states basic function and does not mention pagination, rate limits, authentication, error handling, or response format. The schema provides parameter details but description lacks behavioral context.

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, 16 words, no redundancy. Every word serves a purpose. Front-loaded with main action.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With 7 parameters, no output schema, and no annotations, the description is too brief. It fails to specify return structure, ordering, error handling, or scope (news articles? all articles?). Incomplete for a search tool.

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 detailed descriptions for each parameter (e.g., query format, date formats). The description adds minimal information beyond schema (just lists filter types). Baseline 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?

Clearly states 'Find articles by keywords and allows filtering' which specifies the verb (find/search), resource (articles), and differentiates from sibling tools like get_article_content (single article) or get_random_article (random).

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 for keyword-based filtering but does not explicitly state when to use or not use this tool versus alternatives. No exclusions or prerequisites mentioned.

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

search_publishersA

Find a list of publishers with details like descriptions, logos, languages, categories, and links to their social media.

ParametersJSON Schema

Name	Required	Description
`query`	Yes	Just type what you're looking for.
`country`	No	2-letter ISO 3166-1 code of the country.
`language`	No	2-letter ISO 3166-1 code of the language.
`category`	No	Possible options: general, business, entertainment, lifestyle, politics, science, sports, technology.
`sort`	No	Possible options: popularity, relevancy.

TDQS

A3.7/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 mentions returned details (descriptions, logos, languages, categories, social media links) but does not disclose pagination, rate limits, or authentication needs.

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 redundancy, directly states purpose and example outputs.

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?

No output schema, no annotations. Description lists expected fields but lacks details about response format, pagination, or limits. Adequate but not thorough.

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%, so schema already describes parameters. Description adds no extra meaning beyond the schema, only lists example return fields.

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?

Description clearly states the verb 'Find' and resource 'publishers', and lists examples of returned details. It distinguishes from siblings like search_articles which searches articles.

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?

Clear purpose but no explicit guidance on when to use vs alternatives like search_articles, or exclusions. Implicit usage context only.

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

supported_countriesA

This endpoint provides a list of supported countries along with their respective languages.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A3.8/5.0

Behavior3/5

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

No annotations. Description gives basic behavior but lacks details like output format, whether data is static or dynamic, or any caching behavior. Adequate for a simple list endpoint.

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 redundant information. Efficiently conveys purpose.

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?

Given no parameters and no output schema, description covers essential purpose. Could mention output format, but still sufficiently complete for a straightforward list tool.

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?

No parameters, schema coverage 100%. Description provides context on return content (countries and languages), adding value beyond empty 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?

Description clearly states the tool provides a list of supported countries with languages. Verb 'provides' and resource 'list of supported countries' are specific. Distinguishes from siblings like supported_languages.

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 alternatives (e.g., supported_languages, supported_topics). Context of use is not mentioned.

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

supported_languagesA

This endpoint provides a list of supported languages.

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 but only says 'provides a list' without disclosing any behavioral traits like caching, static vs dynamic, or rate limiting.

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 with no unnecessary words, front-loaded and efficient.

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?

No output schema and simple purpose; however, description could include what format the languages are returned in (e.g., codes, names) to be fully complete.

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?

Input schema has no parameters, so schema description coverage is 100%. The description adds no additional parameter meaning, but baseline for zero params is 4.

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 that the tool provides a list of supported languages, which is a specific and distinct purpose relative to sibling tools like supported_countries or supported_topics.

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?

No explicit guidance on when to use this tool versus alternatives. However, given zero parameters and a simple list, the context is implied but not differentiated.

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

supported_topicsB

This endpoint provides information about the supported topics. Access to the specific topics may be restricted based on your subscription plan.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

B3.2/5.0

Behavior2/5

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

With no annotations, the description should disclose behavioral traits. It only mentions access restrictions, lacking details on read-only nature, rate limits, or mutation behavior.

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?

Single sentence, concise. However, it could be more structured without being verbose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

No output schema or annotations. Description is minimal and does not clarify what 'information' means (e.g., list of topic names, IDs). Insufficient for a complete understanding.

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?

No parameters in schema, so baseline is 4. Description adds context about subscription restrictions, providing some additional meaning.

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?

The description states it provides information about supported topics, which is clear. It distinguishes from sibling tools like search_articles or trending_topics.

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 when needing info on supported topics and mentions subscription restrictions, but does not explicitly state when to use versus alternatives.

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

trending_topicsB

This endpoint lets you find the most popular news article for a specific country, language, and topic (like sports or entertainment).

ParametersJSON Schema

Name	Required	Description	Default
`date`	No	Example value:
`topic`	Yes	The topic of interest, example: General, Politics, Sports, or a subtopic Soccer. Check out the Supported Topics endpoint to see a list of all the topics you can search for.
`language`	Yes	example: en, fr, de, zh-Hant. Check out the Supported Languages endpoint to see a list of all the languages you can search for.
`country`	No	example: us, in, fr, de, id . Check out the Supported Countries endpoint to see a list of all the countries you can search for.
`limit`	No	This parameter controls the maximum number of articles returned on a single page.	0
`page`	No	This parameter specifies the page number you want to access. For example, page=2 will return the second page of results.	0

TDQS

B3.3/5.0

Behavior2/5

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

No annotations are provided, so the description must carry the full burden. It mentions 'most popular' but does not define popularity criteria (e.g., recency, views). Pagination behavior is only hinted at via parameters; no mention of default limits, total results, or ordering. The description lacks important behavioral details beyond the schema.

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?

The description is a single sentence that is direct and front-loaded. It earns its place by stating the core functionality. However, it could be slightly more informative without being verbose, such as clarifying what 'most popular' means.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema and no annotations, the description is insufficient. It does not explain the return format, pagination mechanics, or how 'popular' is determined. For a tool with 6 parameters, the description should provide more context to help the agent use it effectively.

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?

Input schema coverage is 100% with descriptions for all 6 parameters. However, the main description adds no additional semantic value beyond restating the parameters in a general way. The schema already provides examples and references to other endpoints, so the description does not enhance understanding significantly.

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 finds the most popular news article based on country, language, and topic. The verb 'find' and resource 'most popular news article' are specific. It distinguishes from sibling tools like search_articles which are for general searching, not trending.

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 trending content but does not explicitly state when to use this tool over alternatives like search_articles or get_random_article. No guidance on exclusions or prerequisites, but the context of 'most popular' provides some implicit direction.

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. Dates show when Glama detected each change.

8 tool updatesv1.0.0May 17, 2026
- First observedget_article_content
- First observedget_random_article
- First observedsearch_articles
- First observedsearch_publishers
- First observedsupported_countries
- First observedsupported_languages
- First observedsupported_topics
- First observedtrending_topics

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

B3.4/5.0

Disambiguation5/5

Each tool serves a distinct purpose: retrieving article content, random selection, keyword search, publisher search, and various metadata lookups. No two tools overlap significantly.

Naming Consistency4/5

All names use snake_case and are descriptive. However, not all follow a strict verb_noun pattern (e.g., supported_countries, trending_topics are adjective_noun), causing minor inconsistency.

Tool Count5/5

With 8 tools, the set is well-scoped for a news API covering search, retrieval, and metadata. Each tool earns its place without being excessive or too few.

Completeness4/5

The set covers core news operations: search, random, content, publishers, and supported metadata. Missing direct topic-based article listing (aside from trending) and publisher filtering, but overall coverage is solid.

Maintenance

ActivityInactive

ResponsivenessSyncing

Resources

GitHub Repository

Need Help?

Reddit Discussion

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Newsdata A
io.github.pipeworx-io
NewsData.io MCP — wraps the NewsData.io global news API (newsdata.io)
Search Research & Data
342
Google News data for agents A
sh.fetcher.google-news
12 Google News endpoints. Pay per call in USDC via x402.
Search Open Data
61
google-newsOAuth
io.github.johnisanerd
Google News headlines, sources, and links via the Apify Google News API, hosted MCP.
Search Web Scraping
2
Search1API AOAuth
io.github.superagents-lab
Web search, news, page retrieval, sitemaps, and trending topics through Search1API.
Search Browser Automation
51173

Related MCP Servers

Mediastack News MCP Server
Search
rftsngl
A
license
Not graded
quality
D
maintenance
Provides access to the Mediastack News API, enabling users to fetch the latest news stories and browse news sources with filtering options by keywords, countries, languages, and categories.
Updated 10 months ago (2025-10-26 14:30 UTC)
1
MIT
GNews MCP Server
Search
JerripotulaSriharsha
F
license
Not graded
quality
D
maintenance
Enables searching news articles and retrieving top headlines from the GNews API with support for filtering by topic, language, and country.
Updated 8 months ago (2026-01-07 17:35 UTC)
-
News API MCP Server
Search Open Data
kcjonnyc
F
license
Not graded
quality
D
maintenance
Enables AI assistants to search news articles, get top headlines, and browse sources via the NewsAPI.org service.
Updated a year ago (2025-05-30 18:41 UTC)
-
GNews MCP Server
Search Entertainment & Media
OriShmila
F
license
Not graded
quality
D
maintenance
Enables searching news articles and fetching top headlines via GNews API with filtering options.
Updated a year ago (2025-08-20 13:45 UTC)
-

Appeared in Searches

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/BACH-AI-Tools/bachai-news-api14'

If you have feedback or need assistance with the MCP directory API, please join our Discord server