Skip to main content
Glama
dineshrajdhanapathyDD

NewsPulse MCP

⚡ NewsPulse MCP — AI Tech News Aggregator

Python 3.11+ License MIT MCP Amazon Bedrock

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

NewsPulse MCP Architecture

Process Flow — How Data Moves

processflow MCP.drawio.png

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:8000

Note: 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-mcp

Step 3: Install Dependencies

pip install -r requirements.txt

This 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 .env

Step 5: Configure AWS (Optional — for summarization only)

aws configure

Enter your:

  • AWS Access Key ID

  • AWS Secret Access Key

  • Default region: us-east-1

  • Output 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 --help

Expected output:

usage: newspulse-mcp [-h] [{serve,dashboard}]
NewsPulse MCP Server — Technology news aggregation via MCP protocol

Step 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_mcp

Connect 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"

latest_news

"Search for Amazon Bedrock articles"

search_news

"Summarize this article: https://..."

summarize_article

"What's trending in tech?"

trending_topics

"Compare AWS Blog vs GitHub Blog on AI"

compare_sources

"Bookmark that article"

bookmark_article

"Show my saved articles"

saved_articles

"Give me today's tech digest"

daily_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 dashboard

Open 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

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: json

Step 2: Enable Model Access

  1. Go to Amazon Bedrock Console

  2. Click "Manage model access"

  3. Enable Amazon Nova Lite (or Nova Micro/Pro)

  4. 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=512

No 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-mcp

Docker Compose

docker-compose up -d

Dashboard at http://localhost:8000. SQLite data persisted in ./data/.


Demo Flow

  1. python -m newspulse_mcp dashboard — Start the dashboard

  2. Open http://localhost:8000 — See the home page

  3. Click Latest News — Live articles from all RSS feeds

  4. Filter by "AWS" category — Only AWS articles shown

  5. Click Search → type "Bedrock" → see matching articles

  6. Click Trending — See most discussed technologies

  7. Click Bookmark on any article — Saved to your library

  8. Click Bookmarks — See your saved articles

  9. Click Daily Digest — Last 24 hours grouped by category

  10. 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 file

Environment Variables

Variable

Description

Default

AWS_REGION

AWS region for Bedrock

us-east-1

BEDROCK_MODEL_ID

Nova model for summarization

amazon.nova-lite-v1:0

BEDROCK_TEMPERATURE

LLM temperature (0.0–1.0)

0.3

BEDROCK_MAX_TOKENS

Max summary tokens

512

BEDROCK_TOP_P

Nucleus sampling

0.9

SUMMARIZATION_ENABLED

Enable/disable summarization

true

DATABASE_PATH

SQLite file path

./newspulse.db

LOG_LEVEL

Logging level

INFO


Running Tests

# Run all tests
python -m pytest tests/ --tb=short

# Run with coverage
python -m pytest tests/ --cov=newspulse_mcp --cov-report=term-missing

Troubleshooting

Issue

Solution

ModuleNotFoundError

Run pip install -r requirements.txt

RuntimeError: Already running asyncio

Make sure you're using the latest main.py (fixed)

Summarization disabled

Run aws configure and enable Nova in Bedrock console

Dashboard shows raw HTML

Restart the server (Ctrl+C then re-run)

Can't access http://0.0.0.0:8000

Use http://localhost:8000 instead

404 /favicon.ico

Harmless — already fixed with inline SVG favicon

Kiro doesn't see tools

Check mcp.json path and restart Kiro


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 tools
bookmark_articleA

Bookmark an article for later reference.

ParametersJSON Schema
NameRequiredDescriptionDefault
urlYesArticle URL
titleYesArticle title
source_nameYesName of the source
published_dateYesISO 8601 date string (e.g., "2024-01-15T10:30:00+00:00")

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

A3.6/5.0
Behavior2/5

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.

Conciseness5/5

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.

Completeness4/5

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.

Parameters3/5

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.

Purpose5/5

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.

Usage Guidelines3/5

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.

ParametersJSON Schema
NameRequiredDescriptionDefault
topicYesTopic to compare coverage on
source_aYesFirst source name (must match a configured feed name)
source_bYesSecond source name (must match a configured feed name)

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

C2.8/5.0
Behavior2/5

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.

Conciseness3/5

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.

Completeness2/5

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.

Parameters3/5

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.

Purpose4/5

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.

Usage Guidelines2/5

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

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

A3.9/5.0
Behavior3/5

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.

Conciseness5/5

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.

Completeness5/5

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.

Parameters4/5

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.

Purpose5/5

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.

Usage Guidelines2/5

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.

ParametersJSON Schema
NameRequiredDescriptionDefault
categoryYesTechnology category to filter by (e.g., "AWS", "AI", "Python", "DevOps", "Kubernetes", "GitHub")

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

A3.6/5.0
Behavior3/5

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.

Conciseness5/5

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.

Completeness4/5

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.

Parameters3/5

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.

Purpose5/5

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.

Usage Guidelines2/5

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

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

A4.2/5.0
Behavior4/5

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.

Conciseness5/5

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.

Completeness4/5

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.

Parameters4/5

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.

Purpose5/5

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.

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 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.

ParametersJSON Schema
NameRequiredDescriptionDefault
keywordYesNon-empty search term to find in article titles and summaries

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

B3/5.0
Behavior2/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 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.

Conciseness3/5

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.

Completeness2/5

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.

Parameters3/5

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.

Purpose5/5

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.

Usage Guidelines2/5

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.

ParametersJSON Schema
NameRequiredDescriptionDefault
urlYesFull URL of the article to summarize

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

B3.1/5.0
Behavior2/5

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.

Conciseness4/5

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.

Completeness2/5

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.

Parameters3/5

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.

Purpose5/5

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.

Usage Guidelines2/5

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.

TDQS

A3.7/5.0
Disambiguation5/5

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.

Naming Consistency5/5

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.

Tool Count5/5

8 tools is well-scoped for a news aggregation server, covering essential features without unnecessary bloat or deficiency.

Completeness4/5

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

ActivitySlowing
ResponsivenessSyncing

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

Related MCP Servers

Latest Blog Posts

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