news-mcp-server
Server Details
Cross-source news (AP, BBC, NPR, HN, Google News) with topic filtering and dedup.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 4.2/5 across 5 of 5 tools scored.
Each tool targets a distinct source (AP, BBC, Hacker News, NPR) or a search function, with no overlapping purposes. Descriptions clearly differentiate them.
All tool names follow a consistent get_<source> pattern (get_ap_news, get_bbc_news, etc.) and search_google_news matches the verb_noun style. No mixing of conventions.
With 5 tools covering major news sources plus a search, the count is well-scoped for a news aggregation server. Each tool serves a clear purpose without redundancy.
The set covers multiple major sources and provides a search tool for broader coverage. Missing capabilities like category filtering across sources or fetching by date range are minor gaps.
Available Tools
5 toolsget_ap_newsARead-onlyInspect
Fetch breaking news and headlines from Associated Press (AP News), a leading global news agency. Returns article title, summary, canonical URL, publication timestamp, and journalist byline. Use for current events coverage, news monitoring, or building newsfeeds. Best for recent breaking stories published within 24 hours.
| Name | Required | Description | Default |
|---|---|---|---|
| max_results | No | Number of recent articles to fetch (default 10, max 100 for pagination) |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint and openWorldHint. Description adds that it returns recent stories within 24 hours and lists specific fields. No contradiction, but could add details on pagination or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with purpose, followed by details and usage. No wasteful words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, description adequately explains return fields and freshness. Enough context for a simple read-only fetch tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and already includes default and max for max_results. Description adds context that results are articles but no new parameter semantics beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool fetches breaking news and headlines from AP News, listing returned fields. It distinguishes from sibling tools by specifying the source (AP News) and content type.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit use cases (current events, news monitoring, newsfeeds) and notes best for recent stories within 24 hours. Does not explicitly mention when not to use or direct to siblings, but sibling names are available from context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_bbc_newsARead-onlyInspect
Retrieve latest news stories from BBC News covering global, regional, and domestic stories. Returns headline, synopsis, article URL, publish date, and section (world/uk/business/tech). Use for UK perspective on international news or UK-focused stories. Includes categories for targeted browsing.
| Name | Required | Description | Default |
|---|---|---|---|
| max_results | No | Number of articles to retrieve (default 10, higher values may include older stories) |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint and openWorldHint. Description adds output fields but no additional behavioral traits like rate limits or auth. With annotations, the bar is lower; description contributes moderate context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences with no waste, front-loaded with action and resource. Each sentence adds value: purpose, output, use case.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Simple tool with one parameter and no output schema; description covers purpose, output fields, and use case. Lacks mention of edge cases like empty results or errors, but sufficient for typical use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the single parameter max_results, and description mentions 'higher values may include older stories,' which duplicates schema. No new semantic meaning beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves latest BBC News stories, lists specific output fields (headline, synopsis, URL, publish date, section), and differentiates from siblings by emphasizing UK perspective and categories.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly advises use for 'UK perspective on international news or UK-focused stories,' indicating when to use. Does not specify when not to use or mention alternatives, but context from sibling tools is available.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_hacker_newsARead-onlyInspect
Pull top trending stories from Hacker News (Y Combinator community). Returns submission title, original URL, Hacker News discussion link, upvote count, comment count, and user who submitted. Use for tech news, startup stories, and developer-relevant content. Ranked by community engagement.
| Name | Required | Description | Default |
|---|---|---|---|
| max_results | No | Number of top stories to fetch (default 20, captures trending and popular items) |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so no need to restate. Description adds value by detailing what the tool returns (title, URLs, counts) and that results are 'ranked by community engagement', which annotations don't cover.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is concise (4 sentences), front-loaded with main action, and logically structured: what it does, what it returns, when to use, and ranking method. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given simple read-only tool with one parameter and no output schema, the description fully covers purpose, return fields, and usage context. Agent has all needed information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with clear description for max_results (default 20, captures trending items). The tool description does not add extra semantic beyond the schema, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it pulls top trending stories from Hacker News and lists the fields returned. It distinguishes from siblings (AP, BBC, NPR, search) by specifying the domain (tech news, startup stories), making selection easy.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit usage guidance: 'Use for tech news, startup stories, and developer-relevant content.' Does not list when not to use, but sibling names imply alternatives for other news types.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_npr_newsARead-onlyInspect
Access curated news stories from NPR (National Public Radio) with focus on US news, science, and culture. Returns article headline, brief summary, direct link to NPR story, and publication metadata. Use for journalistic depth and alternative perspectives on major news events.
| Name | Required | Description | Default |
|---|---|---|---|
| max_results | No | Maximum number of stories to return (default 10, recommended for fresh content) |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true. Description adds that stories are 'curated' with specific focus, but does not reveal additional behavioral traits like rate limits or data freshness beyond schema default.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two efficient sentences: first explains purpose and content, second provides usage guidance. No superfluous words; information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one optional parameter, no output schema, clear annotations), the description fully covers purpose, content returned, and usage context, making it sufficient for an agent to select and invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the single parameter max_results already has a clear description. The tool description does not add extra meaning about parameter usage, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states verb 'access', specific resource 'curated news stories from NPR', and focus areas 'US news, science, and culture'. Lists returned items (headline, summary, link, metadata), distinguishing it from sibling tools like get_ap_news.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly advises using for 'journalistic depth and alternative perspectives on major news events', providing context. Does not explicitly state when not to use or name alternatives, but the advice is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_google_newsARead-onlyInspect
Query Google News for articles matching specific keywords or topics across global news sources. Returns matching article headline, source publication name, article URL, publish date, and relevance score. Use for targeted research on specific topics, people, or events. Returns results sorted by recency.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Search query to find articles (e.g. 'artificial intelligence', 'stock market crash', 'climate change') | |
| max_results | No | Maximum search results to return (default 10, higher values for comprehensive coverage) |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and openWorldHint. Description adds that results are sorted by recency, which is value beyond annotations. No contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, front-loaded with action and output, no wasted words. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, but description enumerates return fields. Two parameters fully documented with examples. Complete for a search tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 100% coverage, so baseline is 3. Description adds examples and notes on max_results ('higher values for comprehensive coverage'), providing extra meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool queries Google News for articles matching keywords/topics, with explicit output fields. It distinguishes itself from sibling tools (get_ap_news, get_bbc_news, etc.) which seem to fetch from single sources.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Says 'Use for targeted research on specific topics, people, or events.' but does not explicitly state when not to use or compare with alternatives (siblings). Implied context but lacks clear exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!