MCP server for news and media data including headlines, articles, RSS feeds, and breaking news from multiple sources for AI agents.
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.
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) |
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.
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) |
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.
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) |
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.
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) |
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.
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) |
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.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
get_ap_news1 field changedInput schema / properties / max_results / descriptionPrevious value: -"Maximum number of articles to return"New value: +"Number of recent articles to fetch (default 10, max 100 for pagination)"get_bbc_news1 field changedInput schema / properties / max_results / descriptionPrevious value: -"Maximum number of articles to return"New value: +"Number of articles to retrieve (default 10, higher values may include older stories)"get_hacker_news1 field changedInput schema / properties / max_results / descriptionPrevious value: -"Maximum number of stories to return"New value: +"Number of top stories to fetch (default 20, captures trending and popular items)"get_npr_news1 field changedInput schema / properties / max_results / descriptionPrevious value: -"Maximum number of articles to return"New value: +"Maximum number of stories to return (default 10, recommended for fresh content)"search_google_news2 fields changedInput schema / properties / max_results / descriptionPrevious value: -"Maximum results"New value: +"Maximum search results to return (default 10, higher values for comprehensive coverage)"Input schema / properties / query / descriptionPrevious value: -"Search query"New value: +"Search query to find articles (e.g. 'artificial intelligence', 'stock market crash', 'climate change')"get_ap_newsget_bbc_newsget_hacker_newsget_npr_newssearch_google_newsClaiming proves that you control a remote MCP connector. It does not move, proxy, or interrupt the server.
Open the connector listing, choose Claim ownership, and sign in to Glama.
Complete one verification method:
GitHub identity – fastest for official registry listings. For a namespace such as io.github.alice/server, link the matching GitHub user, then choose Claim with GitHub. An organization namespace such as io.github.acme/server also needs that organization to have installed the Glama AI GitHub App and approved its permissions, because GitHub discloses organization membership only to apps it has installed. Use HTTP or DNS when it has not.
HTTP challenge – works when you can deploy a public file. Generate a token, publish the exact JSON Glama shows at /.well-known/glama.json on the same origin as the connector, then choose Check HTTP challenge.
DNS challenge – works when you control DNS but cannot change the server. Generate a token, create the exact TXT record Glama shows, wait for it to propagate, then choose Check DNS challenge.
After verification, Glama sends a confirmation email and gives you access to listing details, thumbnails, health checks, and analytics. Keep the HTTP file or DNS record in place: Glama periodically checks it and ownership remains verified while the token is discoverable.
The HTTP ownership file has this structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"claim": "glama_claim_..."
}Claim tokens are opaque, stable, and bound to the signed-in Glama account. They contain no email address or other personal information. If Glama can no longer discover a verified HTTP or DNS token, it starts a seven-day grace period before removing claim-based access. Restore the same token during that period to keep ownership verified. Never publish an email address, Glama session token, GitHub token, or connector credential as ownership proof.
If verification fails, confirm that you copied the current token exactly. The HTTP file must be public, return valid JSON with a successful HTTP response, and stay on the connector's origin. DNS changes may need more time to propagate. A claim cannot transfer to a different origin or hostname: if the connector target changes, Glama starts the grace period and the new target must be claimed separately after the previous claim is released.
For a connector linked to the official MCP Registry, registry updates continue to replace its name, description, and URL by default. After claiming, open Manage connector and enable Use Glama listing details as the source of truth if edits made on Glama should be preserved. Categories and thumbnails are always managed on Glama; registry linkage and technical connection settings continue to sync.
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
To improve your MCP server's ranking:
Claim ownership of the server listing
Complete the server profile with an accurate description and thumbnail
Provide a test profile so Glama can connect to and evaluate the server
Keep tool definitions clear and complete to earn a high Tool Definition Quality Score (TDQS)
Route real usage through the Glama Gateway; more recorded successful server uses also improve the ranking
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!
