ai-news-mcp

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.0.0
Disambiguation4/5
Tools like get_trending_news, get_top_picks, search_today, and get_new_since all return news items but with distinct mechanisms—aggregation, ranking, keyword search, and time-based filtering. Some initial confusion possible between get_trending_news and get_top_picks, but descriptions clarify their unique purposes.
Naming Consistency4/5
Most tools follow a get_ prefix with descriptive nouns (get_repo_quickstart, get_trending_news, get_top_picks, get_paper_brief, get_new_since, get_topic_suggestions), but search_today and check_cache deviate from this pattern. Still, the naming is largely predictable and readable.
Tool Count5/5
With 8 tools covering news aggregation, search, ranking, paper/research lookups, repository quickstarts, topic suggestions, and cache status, the tool count is well-suited to the server's purpose. No tool feels redundant or unnecessary.
Completeness4/5
The tool surface covers the main workflows: retrieving trending news, searching it, getting top picks, fetching paper briefs and repo quickstarts, suggesting blog topics, and checking cache health. Minor omissions like fetching a specific news item by ID or source-specific filtering are workaround-able through search and time-based retrieval.
Average 3.9/5 across 8 of 8 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- 0 of 1 community issues answered or closed in the last 6 months
- 13 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden. It discloses the scoring behavior and the return item format (one-liner 'why it matters' and optional try_url), which adds useful context. However, it does not mention potential side effects, rate limits, or constraints like maximum N, leaving some behavioral traits undisclosed.
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?
The description is two sentences, front-loaded with the primary action ('Returns'), and provides key details (scoring, item format) without waste. Every clause earns its place.
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 the tool's simplicity and complete schema, the description covers purpose, scoring, and return format sufficiently. The absence of usage guidelines and output schema is a minor gap, but the description gives enough for an agent to invoke it correctly. Slightly less complete than a tool with explicit alternatives or richer behavioral notes.
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 description coverage is 100%, and the schema already explains both 'n' and 'category' clearly. The description echoes 'top N' but adds no extra meaning beyond the schema, so the baseline of 3 is appropriate.
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 returns top N relevant items for AI engineers, with a specific scoring methodology (source reputation plus item score). It distinguishes itself by audience and ranking mechanism, though it does not explicitly contrast with sibling tools like get_trending_news or search_today.
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?
There is no guidance on when to use this tool versus alternatives. It does not mention that this is preferable for a curated, reputation-weighted list or that other tools might be better for specific filtering needs. The 'for AI engineers' audience hint is the only contextual clue.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It clearly indicates a read-only operation ('fetches', 'extracts') with no side effects mentioned. However, it does not disclose potential pitfalls such as invalid URLs, missing README sections, or response format details. This is acceptable for a simple tool but lacks depth.
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?
The description is a single, front-loaded sentence with no redundant words. It efficiently conveys both the metadata retrieval and README extraction aspects without unnecessary detail.
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?
With only one parameter, no output schema, and no annotations, the description provides a good overview of the tool's behavior and explicitly lists the key output elements (stars, description, language, topics, install commands, quickstart block). It does not cover edge cases or fallback behavior, but for a simple tool it is reasonably complete.
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?
The schema description covers the singular 'url' parameter with a clear format and example, achieving 100% coverage. The tool description adds no extra parameter meaning beyond this, so the baseline score of 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?
The description clearly states the tool's purpose with a specific verb ('fetches') and resource ('GitHub repo's metadata') and adds detail about extracting README content. It distinguishes itself from sibling tools (news, papers, topics) by explicitly focusing on GitHub repos.
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 when-to-use or alternative guidance is provided. However, the description's specificity makes it clear the tool is for getting repo metadata and quickstart info, which indirectly guides usage. It does not mention any exclusions or alternatives, so it's adequate but not thorough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It mentions checking Supabase connection status and local cache existence, which implies a non-destructive diagnostic operation, but it does not explicitly state whether it has side effects (though 'check' implies read-only). It also doesn't describe potential latency or failure modes, which would be useful.
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?
The description is a single, well-structured sentence. It front-loads the primary action and resource ('check the current state of the news cache') and efficiently lists additional details (e.g., connection status, age, per-source counts) without any redundant words.
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 the simple nature of the tool (zero parameters, no output schema), the description provides a good overview of what the tool examines and what information it reports. It does not specify the return format or error behavior, but for a cache check tool this level of detail is sufficient for an agent to understand its purpose and likely output.
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?
The input schema has zero parameters, so the description trivially covers all schema requirements. Per the rubric, a baseline of 4 applies when there are no parameters, and the description adds useful contextual information about what is being checked without needing to explain any parameter semantics.
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 checks the current state of the news cache and enumerates the exact aspects it reports (connection status, existence, age, per-source item counts). This differentiates it from sibling tools that fetch news content or perform searches.
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 its use for diagnosing cache state, but it does not explicitly state when to use it versus alternatives or provide exclusion criteria. The verb 'check' and the subject make the context clear, but no guidance is given about scenarios where one might prefer another tool or prerequisite conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description provides important behavioral details: it queries (read operation), returns deduplicated and sorted output, and requires a Supabase connection. This covers the main behavioral traits, though it doesn't disclose error handling or empty-result behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, front-loaded with the primary action, followed by key output details and a prerequisite. Every sentence adds value.
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?
For a simple 1-parameter tool with no output schema, the description is fairly complete: it covers what the query does, what it returns, and a requirement. Minor absences like pagination or empty results don't undermine adequacy.
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?
The schema covers the sole parameter 'since' with 100% description coverage, so the baseline is 3. The description only restates that rows are created after the timestamp, adding no new meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description uses a specific verb 'Queries' targeting Supabase cache rows with a temporal filter, and specifies the return behavior (deduplicated news items sorted newest first). This clearly distinguishes it from sibling tools like search_today or get_trending_news.
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 context for using this tool (fetching cache rows after a timestamp) is implied, but there is no explicit comparison to alternatives or exclusions. It doesn't reference sibling tools or 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It clearly states the tool fetches data from ArXiv and searches external sources, implying read-only behavior and network dependency. However, it does not mention potential errors, response format, or rate limits, so it falls short of a perfect score.
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?
The description is two concise sentences, front-loaded with the primary action and followed by the secondary search behavior. Every word adds value, with no filler or redundancy.
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 the low complexity (single parameter, no output schema), the description adequately covers the tool's purpose and behavior. It specifies the fields returned and the external sources searched. It could mention the response format or error handling, but for a simple fetch tool, this is sufficient.
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?
The schema already provides 100% coverage for the single 'url' parameter, including a descriptive example. The description adds no extra semantic detail about the parameter beyond what the schema gives, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Fetches') and clearly names the resource ('ArXiv paper') along with the exact data fields (title, authors, abstract, submission date). It also adds the secondary behavior of searching Papers With Code and GitHub, which distinguishes it from sibling tools like get_repo_quickstart.
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 the tool is for retrieving a paper brief, but it does not explicitly state when to use this tool versus alternatives, nor does it provide any exclusion criteria. Usage context is implied by the tool name and description but not explicitly guided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the transparency burden. It discloses key behaviors: 1-hour caching, reading from Supabase cache first, and falling back to a local file cache. This is valuable context beyond a basic 'get news' statement, though it does not cover rate limits, authentication, or return format.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core purpose and source list, followed by a concise caching note. No wasted words or repetition of schema details.
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 the moderate complexity and lack of output schema, the description adequately explains the aggregation function, sources, and caching strategy. It does not explicitly mention the return structure, but the name implies a list of news items, so this is not a major gap.
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?
The input schema has 100% coverage with clear descriptions for both parameters (refresh and category). The tool description adds no additional parameter context, so the schema already fulfills the semantic load. 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?
The description clearly states what the tool does: aggregates real-time AI/tech news from multiple named sources. The verb 'aggregates' and specific resource list (HackerNews, Dev.to, Reddit, etc.) make the purpose unambiguous and distinguish it from siblings like search_today or get_paper_brief.
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 the tool is for getting trending news from various sources, but it does not explicitly state when to use it over alternatives or provide exclusions. No comparison to sibling tools is made, so guidance is only implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility and does well by disclosing matching against title/summary, the scoring formula (word match count × item score), and that it returns top results. This goes beyond a simple statement and gives useful insight into how results are ranked.
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?
The description is two sentences, front-loaded with the primary action, and contains no redundant or filler content. Every word adds value, making it highly efficient and easy to parse.
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 only 2 parameters, no annotations, and no output schema, the description adequately explains the tool's behavior and intent. It notes the matching scope and scoring, which is enough for an agent to select and call it, though it does not describe the exact return structure.
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 both parameters (query and limit) already described. The description adds the meaning of query as keyword query and the concept of 'top results' but does not significantly expand on the schema's parameter descriptions, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description specifies a clear action ('Search') on a specific resource ('today's cached news') with a scoping method ('by keyword query'). It also details matching and scoring behavior, distinguishing it from sibling tools like get_trending_news or check_cache.
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 keyword-based searches on cached news, but does not explicitly state when to use this tool over alternatives like get_trending_news or get_top_picks. The presence of search semantics provides context, but no direct alternative differentiation or exclusion criteria are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It discloses that the tool relies on trending news, tailors ideas per project, and filters against used topics, which is meaningful. However, it does not mention whether it performs external network calls, any rate limits, or caching behavior, leaving some behavioral aspects unspecified.
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?
A single 23-word sentence that is front-loaded with the main action and includes all essential context. No filler words or redundant phrases.
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?
For a simple suggestion tool with strong schema coverage, the description is complete: it explains the source, tailoring, and filtering. It does not describe return format, but no output schema exists and the tool's output is straightforward. Sibling tool names also provide useful context.
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?
Schema coverage is 100%, so baseline is 3. The description adds value by explaining the purpose of project (tailoring) and used_topics (filtering), but does not mention slots. This extra meaning justifies a 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 the verb 'suggests' and the resource 'blog topic ideas', and specifies the scope: based on trending news, tailored per project, and filtered against used topics. This distinguishes it from sibling tools like get_trending_news (raw news) and get_top_picks (general top picks).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: use it when you need blog topic ideas grounded in trending news for a specific project, with duplicate filtering. It does not explicitly say when not to use it or name alternatives, but the context alone is enough to guide selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![ai-news-mcp MCP server](https://glama.ai/mcp/servers/treesoop/ai-news-mcp/badges/card.svg)](https://glama.ai/mcp/servers/treesoop/ai-news-mcp)

Score Badge

Copy to your README.md:

[![ai-news-mcp MCP server](https://glama.ai/mcp/servers/treesoop/ai-news-mcp/badges/score.svg)](https://glama.ai/mcp/servers/treesoop/ai-news-mcp)

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/treesoop/ai-news-mcp'

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