MCP server for news and media data including headlines, articles, RSS feeds, and breaking news from multiple sources for AI agents.
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.
Average 4.2/5 across 5 of 5 tools scored. Lowest: 3.5/5.
Each tool retrieves news from a distinct source (AP, BBC, HN, NPR, Google News) with no functional overlap, making it easy for an agent to select the correct one.
All tool names follow the consistent 'get_<source>_news' pattern in snake_case, providing a clear and predictable naming convention.
With 5 tools covering major global and niche news sources, the count is well-scoped for the server's purpose without being overwhelming or insufficient.
The set covers a broad range of news sources (global, US, UK, tech), though missing some major outlets like Reuters or an ability to fetch by category, but core retrieval is solid.
get_ap_newsAFetch 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) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, but the description adds value by detailing the return fields (title, summary, URL, timestamp, byline) and the 24-hour recency scope. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no extraneous information. It front-loads the core purpose and follows with usage guidance. Every sentence earns its place.
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 single parameter, high schema coverage, and clear annotations, the description is complete. It covers the tool's output, intended use, and recency constraint, requiring no further elaboration.
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?
The only parameter, max_results, is fully described in the schema (coverage 100%). The tool description does not provide additional context about the parameter beyond what the schema offers, so a baseline score of 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 'Fetch breaking news and headlines from Associated Press (AP News)', specifying the verb 'Fetch' and the resource 'AP News'. It also lists the returned fields, differentiating it from sibling tools like get_bbc_news by naming the source.
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?
The description includes 'Use for current events coverage, news monitoring, or building newsfeeds. Best for recent breaking stories published within 24 hours', providing clear usage context. While it does not explicitly contrast with siblings, the source-specific guidance is sufficient for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_bbc_newsARetrieve 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) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint and openWorldHint. Description adds details on return fields (headline, synopsis, URL, date, section) and notes that higher max_results may include older stories, which is useful behavioral info 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences that front-load the main action, then provide return details and usage guidance. 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?
Given the low complexity (one optional parameter, no output schema), the description fully covers what the tool does, what it returns, and when to use it. No gaps for the agent.
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 covers the single parameter with a description (100% coverage). Description adds value by noting that higher max_results may include older stories, which is not in the 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?
Clearly states it retrieves latest BBC News stories with coverage of global/regional/domestic stories. Differentiates from siblings by emphasizing UK perspective and UK-focused content, distinct from AP, NPR, Hacker News, and Google 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 states when to use ('Use for UK perspective on international news or UK-focused stories'), providing clear context. Does not include explicit exclusions or alternative comparisons, but the context is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_hacker_newsAPull 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) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, so the description adds value by specifying the returned fields (title, URL, discussion link, upvotes, comments, user) and ranking method (community engagement). No contradictory information.
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?
The description is concise (three sentences) and front-loaded with the main action. Every sentence provides essential information without redundancy.
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 simple parameter set and no output schema, the description covers purpose, use case, and return fields adequately. No critical information is missing for an agent to select and invoke the tool 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?
The input schema has 100% coverage for the single parameter (max_results) with its own description and default. The tool description does not repeat parameter details, but the schema already provides sufficient meaning, 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 the verb ('Pull') and the resource ('top trending stories from Hacker News'). It distinguishes from sibling news tools by specifying the source and content type (tech news, startup stories).
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?
The description provides context for when to use this tool: 'Use for tech news, startup stories, and developer-relevant content.' It does not explicitly list exclusions or alternatives, but the sibling names make it clear which news source each tool covers.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_npr_newsAAccess 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) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only and open-world. Description adds context by listing returned fields (headline, summary, link, metadata) and curation aspect, enhancing behavioral understanding.
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 concise sentences, front-loaded with purpose, output, and usage. 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?
For a simple tool with one optional parameter and no output schema, the description fully covers purpose, output, and usage context. No gaps.
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 parameter 'max_results' is well-described in the schema. Description does not add further parameter details, but baseline is adequate.
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?
Clearly states the tool retrieves curated NPR news stories, specifies focus areas (US news, science, culture), and distinguishes from siblings by mentioning 'journalistic depth and alternative perspectives'.
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 a use case ('journalistic depth and alternative perspectives'), implying when to choose NPR over other news sources, but does not explicitly state when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_google_newsAQuery 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) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly (safe) and openWorld (non-deterministic). Description adds that results are sorted by recency. Beyond that, no additional behavioral traits (rate limits, auth) are disclosed.
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. Efficient and no superfluous content, though could be slightly more compact.
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?
Adequately covers purpose, usage context, and return fields for a simple search tool. No output schema but description lists fields. Missing details like language/region filters but not critical for basic 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% and description largely restates schema parameter descriptions without adding new meaning. Baseline 3 is appropriate as no extra value 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?
Clearly states it queries Google News for articles matching keywords, listing returned fields. Differentiates from siblings (specific sources) implicitly as a broader aggregated search, but does not explicitly contrast.
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?
Recommends use for targeted research on topics/people/events. Does not specify when not to use or mention alternatives, though sibling tools imply specific source constraints.
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.
No comments yet. Be the first to start the discussion!
