NewsPulse MCP
Provides access to AWS news blogs and AI-powered article summarization using Amazon Bedrock Nova models.
Integrates DEV Community RSS feed to provide Python and developer articles.
Fetches and searches articles from the GitHub Blog feed for technology updates.
Includes InfoQ RSS feed as a source for DevOps and software engineering news.
Aggregates latest articles from the Kubernetes Blog feed.
Retrieves news from the Python Insider (Python.org) blog feed.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@NewsPulse MCPsummarize the latest AWS news"
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.
⚡ NewsPulse MCP — AI Tech News Aggregator
Built by DD 🚀
A custom MCP (Model Context Protocol) server built from scratch using the AWS Labs FastMCP SDK. Connects to live RSS feeds and exposes them as MCP tools that Kiro, Claude Desktop, or any MCP client can discover and use. Powered by Amazon Bedrock (Nova) for article summarization.
Table of Contents
Related MCP server: NewsIQ MCP
The Problem
Developers spend time visiting multiple websites to stay updated with AWS, AI, DevOps, Python, Kubernetes, and GitHub news. This MCP server solves that by giving your AI assistant direct access to live tech news feeds.
What This Does
🔌 Custom MCP Server — 8 tools discoverable by any MCP client
📡 Live RSS Feeds — Real-time articles from 8 tech news sources
🤖 AI Summarization — Amazon Bedrock Nova summarizes articles in 3-5 sentences
🔍 Smart Search — Keyword search with relevance ranking
🔥 Trending Analysis — Identifies most-discussed technologies
🔖 Bookmarks — Save articles to local SQLite database
📋 Daily Digest — Last 24 hours grouped by category
🖥️ Web Dashboard — Visual interface at localhost:8000
Architecture
System Architecture

Process Flow — How Data Moves

The MCP server and FastAPI dashboard share a common service layer. Both consume the same RSS, search, summarization, bookmark, and digest services keeping behavior consistent regardless of interface.
Quick Start (5 Minutes)
# 1. Clone
git clone https://github.com/DD-GITH-UB/newspulse-mcp.git
cd newspulse-mcp
# 2. Install
pip install -r requirements.txt
# 3. Configure
copy .env.example .env
# 4. Run MCP Server
python -m newspulse_mcp serve
# 5. Or run the Web Dashboard
python -m newspulse_mcp dashboard
# Open http://localhost:8000Note: Summarization requires AWS credentials. All other tools (news, search, trending, bookmarks) work without any API keys.
Step-by-Step Setup
Step 1: Prerequisites
Requirement | Purpose | Required? |
Python 3.11+ | Runtime | ✅ Yes |
pip | Package manager | ✅ Yes |
AWS CLI | Bedrock credentials | ⚠️ Only for summarization |
Git | Clone repo | ✅ Yes |
Step 2: Clone the Repository
git clone https://github.com/DD-GITH-UB/newspulse-mcp.git
cd newspulse-mcpStep 3: Install Dependencies
pip install -r requirements.txtThis installs: fastmcp, fastapi, httpx, feedparser, beautifulsoup4, aiosqlite, boto3, structlog, and more.
Step 4: Create Environment File
# Windows
copy .env.example .env
# Mac/Linux
cp .env.example .envStep 5: Configure AWS (Optional — for summarization only)
aws configureEnter your:
AWS Access Key ID
AWS Secret Access Key
Default region:
us-east-1Output format:
json
Then enable the model in Amazon Bedrock Console → Request access to Amazon Nova Lite.
Step 6: Verify Everything Works
python -m newspulse_mcp --helpExpected output:
usage: newspulse-mcp [-h] [{serve,dashboard}]
NewsPulse MCP Server — Technology news aggregation via MCP protocolStep 7: Run
# MCP Server (for Kiro/Claude)
python -m newspulse_mcp serve
# Web Dashboard (for browser)
python -m newspulse_mcp dashboard
# Both simultaneously
python -m newspulse_mcpConnect to Kiro IDE
Option A: Workspace-level config
Create .kiro/settings/mcp.json in your workspace:
{
"mcpServers": {
"newspulse": {
"command": "python",
"args": ["-m", "newspulse_mcp", "serve"],
"cwd": "/path/to/newspulse-mcp"
}
}
}Option B: User-level config (global)
Edit ~/.kiro/settings/mcp.json and add newspulse to the existing mcpServers:
{
"mcpServers": {
"newspulse": {
"command": "python",
"args": ["-m", "newspulse_mcp", "serve"],
"cwd": "C:\\path\\to\\newspulse-mcp"
}
}
}Usage in Kiro
Once connected, just ask naturally:
What you say | Tool invoked |
"Show me today's AWS news" |
|
"Search for Amazon Bedrock articles" |
|
"Summarize this article: https://..." |
|
"What's trending in tech?" |
|
"Compare AWS Blog vs GitHub Blog on AI" |
|
"Bookmark that article" |
|
"Show my saved articles" |
|
"Give me today's tech digest" |
|
Connect to Claude Desktop
Edit your Claude Desktop config file:
Windows: %APPDATA%\Claude\claude_desktop_config.json
Mac: ~/Library/Application Support/Claude/claude_desktop_config.json
{
"mcpServers": {
"newspulse": {
"command": "python",
"args": ["-m", "newspulse_mcp", "serve"],
"cwd": "C:\\path\\to\\newspulse-mcp"
}
}
}Restart Claude Desktop. The 8 tools will appear in the tools menu.
Web Dashboard
python -m newspulse_mcp dashboardOpen http://localhost:8000 in your browser.
Pages
Page | Description |
🏠 Home | Feature overview with quick links |
📰 Latest News | Live articles with category filter (AWS, AI, Python, etc.) |
🔍 Search | Keyword search across all feeds |
🔥 Trending | Most discussed technologies with frequency |
📋 Daily Digest | Last 24 hours grouped by category |
🔖 Bookmarks | Your saved articles |
⚙️ Settings | Server config, feeds, Bedrock status |
MCP Tools Reference
latest_news
Retrieve latest articles filtered by category.
Input: category (AWS, AI, Python, DevOps, Kubernetes, GitHub)
Output: Articles with title, source, date, summary, URL
search_news
Search all feeds for keyword matches.
Input: keyword (e.g., "Amazon Bedrock", "Lambda", "MCP")
Output: Ranked articles by relevance
summarize_article
Download and summarize an article using Amazon Bedrock Nova.
Input: url (full article URL)
Output: Title, 3-5 sentence summary, reading time, source
Requires: AWS credentials with Bedrock access
trending_topics
Analyze all recent articles for frequently mentioned technologies.
Input: None Output: Topics with frequency counts, sorted descending
compare_sources
Compare how two news sources cover the same topic.
Input: source_a, source_b, topic
Output: Similarities and differences in coverage
bookmark_article
Save article metadata to local SQLite database.
Input: title, url, source_name, published_date
Output: Success/already bookmarked message
saved_articles
Retrieve all bookmarked articles.
Input: None Output: All bookmarks ordered by save date (newest first)
daily_digest
Generate a digest of articles from last 24 hours.
Input: None Output: Articles grouped by category
RSS Feed Sources
Source | Category | URL |
AWS News Blog | AWS | aws.amazon.com/blogs/aws/feed/ |
AWS Machine Learning Blog | AI | aws.amazon.com/blogs/machine-learning/feed/ |
Python Insider | Python | blog.python.org/feeds/posts/default |
Kubernetes Blog | Kubernetes | kubernetes.io/feed.xml |
GitHub Blog | GitHub | github.blog/feed/ |
Hacker News | DevOps | hnrss.org/frontpage |
InfoQ | DevOps | feed.infoq.com/ |
DEV Community | Python | dev.to/feed |
Add your own feeds by editing newspulse_mcp/feeds_config.yaml — no code changes needed.
Amazon Bedrock Setup (Summarization)
The summarize_article tool uses Amazon Bedrock's Converse API with Amazon Nova.
Step 1: Configure AWS CLI
aws configure
# AWS Access Key ID: your-key
# AWS Secret Access Key: your-secret
# Default region: us-east-1
# Default output: jsonStep 2: Enable Model Access
Go to Amazon Bedrock Console
Click "Manage model access"
Enable
Amazon Nova Lite(or Nova Micro/Pro)Wait for access to be granted (~1 minute)
Step 3: Configure Model (Optional)
Edit .env to change the model:
# Available models:
# amazon.nova-micro-v1:0 — Fastest, cheapest (text-only)
# amazon.nova-lite-v1:0 — Good balance (default)
# amazon.nova-pro-v1:0 — Highest quality
BEDROCK_MODEL_ID=amazon.nova-lite-v1:0
BEDROCK_TEMPERATURE=0.3
BEDROCK_MAX_TOKENS=512No AWS Account?
All other tools work without Bedrock you'll just see a "summarization disabled" message for that one tool. News, search, trending, bookmarks, and digest all use live RSS feeds directly.
Docker Deployment
Build and Run
docker build -t newspulse-mcp .
docker run -p 8000:8000 --env-file .env newspulse-mcpDocker Compose
docker-compose up -dDashboard at http://localhost:8000. SQLite data persisted in ./data/.
Demo Flow
python -m newspulse_mcp dashboard— Start the dashboardOpen
http://localhost:8000— See the home pageClick Latest News — Live articles from all RSS feeds
Filter by "AWS" category — Only AWS articles shown
Click Search → type "Bedrock" → see matching articles
Click Trending — See most discussed technologies
Click Bookmark on any article — Saved to your library
Click Bookmarks — See your saved articles
Click Daily Digest — Last 24 hours grouped by category
Connect Kiro → Ask "Show today's AI news" → MCP tools invoked automatically
Project Structure
newspulse-mcp/
├── newspulse_mcp/
│ ├── main.py # Entry point (serve/dashboard/both)
│ ├── feeds_config.yaml # RSS feed configuration
│ ├── config/ # Settings, feed loader, logging
│ ├── models/ # Article, Bookmark, Error dataclasses
│ ├── services/ # RSS, Search, Trending, Summarizer, etc.
│ ├── parser/ # BeautifulSoup article extraction
│ ├── database/ # SQLite connection + bookmark repository
│ ├── mcp_tools/ # FastMCP tool definitions (8 tools)
│ └── dashboard/ # FastAPI app, routes, templates, CSS
├── tests/ # Unit + integration tests (100+ tests)
├── .env.example # Environment variable template
├── .kiro/specs/ # Kiro spec files (requirements, design, tasks)
├── Dockerfile # Container image
├── docker-compose.yml # Local orchestration
├── requirements.txt # Python dependencies
├── pyproject.toml # Project metadata
├── LICENSE # MIT License
└── README.md # This fileEnvironment Variables
Variable | Description | Default |
| AWS region for Bedrock |
|
| Nova model for summarization |
|
| LLM temperature (0.0–1.0) |
|
| Max summary tokens |
|
| Nucleus sampling |
|
| Enable/disable summarization |
|
| SQLite file path |
|
| Logging level |
|
Running Tests
# Run all tests
python -m pytest tests/ --tb=short
# Run with coverage
python -m pytest tests/ --cov=newspulse_mcp --cov-report=term-missingTroubleshooting
Issue | Solution |
| Run |
| Make sure you're using the latest |
| Run |
Dashboard shows raw HTML | Restart the server ( |
Can't access | Use |
| Harmless — already fixed with inline SVG favicon |
Kiro doesn't see tools | Check |
Future Improvements
Article caching layer to reduce redundant feed fetches
Full-text search with SQLite FTS5
WebSocket live feed updates
User-configurable feed lists via dashboard
Export bookmarks to Markdown/JSON
Multi-user authentication
Scheduled digest via email/Slack
More RSS sources (TechCrunch, The Verge, etc.)
Author
Built by DD with Kiro IDE and Amazon Bedrock.
License
This project is licensed under the MIT License. See LICENSE for details.
Available Tools
8 toolsbookmark_articleA
Bookmark an article for later reference.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | Article URL | |
| title | Yes | Article title | |
| source_name | Yes | Name of the source | |
| published_date | Yes | ISO 8601 date string (e.g., "2024-01-15T10:30:00+00:00") |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden. While 'bookmark' implies a non-destructive save, the description does not disclose potential side effects (e.g., overwriting existing bookmarks), authentication needs, or rate limits. It adds minimal behavioral context beyond the name.
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 a single sentence (10 words) that efficiently conveys the tool's purpose with no superfluous information. Every word 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?
For a simple bookmarking tool with clear schema and an output schema (though not shown), the description is largely sufficient. The sibling tools provide context for differentiation. However, the lack of behavioral details slightly reduces completeness.
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?
All 4 parameters are documented in the input schema with clear descriptions (e.g., 'ISO 8601 date string' for published_date). The description adds no additional meaning; the schema already provides sufficient semantics, 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.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Bookmark an article for later reference' uses a specific verb ('bookmark') and resource ('article'), clearly stating the tool's action and distinguishing it from siblings like 'latest_news' or 'saved_articles' which have different purposes.
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?
No guidance is provided on when to use this tool versus alternatives (e.g., 'saved_articles' to retrieve bookmarks, or 'summarize_article' for a different action). The usage context is implied but not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
compare_sourcesC
Compare how two sources cover the same topic.
| Name | Required | Description | Default |
|---|---|---|---|
| topic | Yes | Topic to compare coverage on | |
| source_a | Yes | First source name (must match a configured feed name) | |
| source_b | Yes | Second source name (must match a configured feed name) |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the burden. It states only that it compares coverage, with no disclosure about side effects, idempotency, or other behavioral traits beyond the implied read-only nature.
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 a single sentence, which is concise but arguably too sparse. It could provide more detail without becoming verbose, so it does not fully earn its place with meaningful content.
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?
With an output schema present, the description need not explain return values, but it lacks context on the nature of the comparison (e.g., showing differences, similarities, biases). For a 3-parameter tool, this feels incomplete.
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%, so the schema already describes all parameters. The description adds no additional meaning beyond what is in the schema, resulting in a baseline score.
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 compares coverage of a topic from two sources. It distinguishes from sibling tools like latest_news or summarize_article by its comparative nature, though the verb 'compare' could be more specific.
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?
No guidance is provided on when to use this tool versus alternatives (e.g., search_news for single-source analysis) or what prerequisites are needed (e.g., source names must match configured feeds).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
daily_digestA
Generate a digest of articles from the last 24 hours grouped by category.
Returns: dict with keys: - categories: list of {category, articles} groupings - message: descriptive message if no recent articles
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries the burden. It discloses the time scope (last 24 hours) and grouping by category, which are key behaviors. However, it omits potential details like rate limits, auth needs, or what happens when no articles exist (though the return dict partially covers the latter).
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 extremely concise with two sentences, no unnecessary words, and front-loads the core purpose.
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 (0 parameters, output schema present), the description adequately covers behavior and return format. It is complete for an agent to understand input, operation, and output.
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?
No parameters exist, so the schema coverage is trivially 100%. The description adds value beyond the schema by detailing the return structure, which is appropriate for a zero-parameter tool.
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 'Generate a digest of articles from the last 24 hours grouped by category,' which specifies a unique verb and resource, and distinguishes it from siblings like latest_news or search_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?
No guidance on when to use this tool versus alternatives (e.g., latest_news, trending_topics). The description does not mention when not to use or provide comparisons to siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
latest_newsA
Retrieve the latest news articles filtered by category.
| Name | Required | Description | Default |
|---|---|---|---|
| category | Yes | Technology category to filter by (e.g., "AWS", "AI", "Python", "DevOps", "Kubernetes", "GitHub") |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries burden. States it retrieves articles, implying read-only. However, lacks details on time range, pagination, or response format, which are relevant for a 'latest' news tool.
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?
Single sentence, front-loaded with purpose, no extraneous information. Highly efficient.
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 required parameter and output schema provided. Description is sufficient for basic use, though could mention that it returns a list of articles. Overall adequate.
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% with a list of examples. The tool description adds no extra parameter semantics beyond the schema, earning baseline 3 per guidelines.
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 'retrieve' and resource 'latest news articles' with filtering by category. Distinguishes from sibling tools like search_news (specific queries) and trending_topics (global trends).
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?
No guidance on when to use this tool versus alternatives. Does not mention prerequisites, when not to use, or compare to siblings like search_news or daily_digest.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
saved_articlesA
Retrieve all bookmarked articles ordered by bookmark timestamp descending.
Returns: dict with keys: - articles: list of bookmarked article dicts with id, title, url, source_name, published_date, bookmarked_at - count: number of bookmarks
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It declares the operation is read-only, returns sorted results in descending order, and specifies the return format and keys. Could mention behavior when no bookmarks exist, but overall good.
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?
Extremely concise: one sentence for action, then clear bulleted list for return format. No fluff, front-loaded with purpose.
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 zero parameters and no annotations, the description covers the core functionality and return format. Missing details like empty response behavior, but still sufficient for selection and invocation.
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?
Input schema has 0 parameters, so there is nothing to describe. According to rubric, 0 params gives baseline of 4. The description adds no parameter info but doesn't need to.
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 it retrieves all bookmarked articles, ordered by bookmark timestamp descending. It uses specific verb 'Retrieve' and resource 'bookmarked articles', and is distinct from siblings like 'latest_news' or 'search_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?
No explicit when-to-use or when-not-to-use guidance. The description implies use when wanting saved articles, but does not differentiate from siblings like 'bookmark_article' or mention alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_newsB
Search all feeds for articles matching a keyword.
| Name | Required | Description | Default |
|---|---|---|---|
| keyword | Yes | Non-empty search term to find in article titles and summaries |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosing behavior. It states the tool searches 'all feeds' but does not elaborate on scope (e.g., number of feeds, update frequency), result ordering, or whether it supports fuzzy matching or case sensitivity. The output schema exists but is not referenced in 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, achieving conciseness, but it may be too brief given the lack of behavioral context. It front-loads the core purpose but omits details that could aid comprehension. It is not wasteful, but feels under-specified.
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?
Despite the presence of an output schema and a simple parameter set, the description does not provide enough context for an agent to fully understand its usage. It fails to mention result format, pagination, or any constraints like language or date range, which are typical 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?
The single parameter 'keyword' is fully described in the input schema (100% schema description coverage), and the description adds no additional nuance beyond that. A score of 3 is appropriate as the schema already does the heavy lifting.
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 action ('Search'), the resource ('all feeds'), and the target ('articles matching a keyword'), making it easy to understand the tool's purpose. It distinguishes itself from siblings like 'latest_news' and 'trending_topics' by focusing on keyword-based search across all feeds.
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?
No guidance is provided on when to use this tool versus alternatives like 'latest_news' (for recent articles) or 'trending_topics' (for popular subjects). The description lacks any when-to-use or when-not-to-use context, leaving the agent to infer based solely on tool names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
summarize_articleB
Download, parse, and summarize an article using LLM.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | Full URL of the article to summarize |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must bear the full burden of behavioral disclosure. It mentions the high-level steps (download, parse, summarize) but omits important behavioral traits such as authentication needs, rate limits, or behavior on inaccessible URLs.
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 a single sentence with 8 words, containing no wasted text. However, it may be too sparse for a tool that performs multiple steps.
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 has an output schema, the description does not need to explain return values, but it lacks context about the summary format, length, or any caveats. The description is insufficiently complete for a tool that involves downloading and parsing external content.
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% for the single required parameter 'url'. The description adds no additional meaning beyond what the schema provides, 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 the tool downloads, parses, and summarizes an article using an LLM. The verb-resource combination is specific and distinct from sibling tools like bookmark_article or latest_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?
No guidance on when to use this tool versus alternatives. The description does not mention exclusions or prerequisites, leaving the agent to infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
trending_topicsA
Identify most frequently discussed technologies across recent articles.
Returns: dict with keys: - topics: list of {name, frequency} ordered by frequency descending - message: descriptive message if no data available
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
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 describes the return format but does not disclose any behavioral traits such as data freshness, source, performance, or whether it is a read-only operation with no side effects.
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 extremely concise: one sentence for purpose and a short return explanation. No redundant information.
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 simplicity (no parameters, output schema exists), the description adequately covers purpose and return structure. However, it could include a brief example or usage hint for more completeness.
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?
There are zero parameters, and schema coverage is 100%. Per the guidelines, a baseline of 4 is appropriate since the description does not need to add parameter info.
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 identifies most frequently discussed technologies across recent articles, which is specific and distinct from sibling tools like latest_news, search_news, or summarize_article.
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 implies when to use (to find trending technologies) but lacks explicit guidance on when not to use or mention of alternatives. No prerequisites or context are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
TDQS
Each tool serves a unique purpose: category-based news, keyword search, summarization, trending topics, source comparison, bookmarking (add/list), and daily digest. No functional overlap.
All tool names follow a clear snake_case pattern with descriptive verbs and nouns (e.g., latest_news, search_news, bookmark_article). Consistent convention throughout.
8 tools is well-scoped for a news aggregation server, covering essential features without unnecessary bloat or deficiency.
Core news workflows are covered: retrieval, search, summarization, trends, comparison, bookmarking, and daily digest. Minor gaps exist (e.g., no update/delete for bookmarks), but the surface is largely complete.
Maintenance
Resources
Unclaimed servers have limited discoverability.
Looking for Admin?
If you are the server author, to access and configure the admin panel.
Related MCP Connectors
Dive into the latest and greatest from the tech world with our Hacker News MCP server.
Driflyte MCP server which lets AI assistants query topic-specific knowledge from web and GitHub.
A MCP server built for developers enabling Git based project management with project and personal…
Cloud-hosted MCP server for durable AI memory
Related MCP Servers
- FlicenseNot gradedqualityDmaintenanceAn MCP server that fetches RSS feeds and shares them with LLMs, allowing AI assistants to access and present the latest news and articles from configured feeds.19
- FlicenseNot gradedqualityCmaintenanceAn AI-powered news aggregator MCP server that fetches live news from multiple sources, provides AI summaries via Claude, and performs sentiment analysis and trending topic detection.
- FlicenseNot gradedqualityDmaintenanceMCP server that fetches and filters AI-related news from 20+ RSS feeds with scheduled notifications and email digests.1
- FlicenseNot gradedqualityBmaintenanceAn MCP server providing real-time access to tech news from Hacker News, GitHub trending repositories, ArXiv papers, and dev.to articles, with capabilities for deep dives and cross-source comparisons.
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
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/dineshrajdhanapathyDD/NewsPulse-MCP'
If you have feedback or need assistance with the MCP directory API, please join our Discord server