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., "@rss-digest-mcp Use get_digest on https://hnrss.org/frontpage and https://zenn.dev/feed, keywords AI and startup, last 24h."
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.
A stateless RSS competitive-intelligence MCP server. Point it at a list of public RSS/Atom feeds — competitor blogs, industry news, release notes, job boards — and get back a keyword-filtered, de-duplicated, recency-sorted digest. No database, no API keys, no login.
"What did my three competitors and the two industry news sites publish in the last 24 hours that mention pricing or layoffs?" — one tool call.
rss-digest-mcp turns a pile of feed URLs into a single, focused digest. It
fetches and parses each feed, keeps only items that (a) are recent enough and
(b) match your keywords, removes duplicates across feeds, sorts newest-first,
and returns clean structured items your LLM can summarise or act on.
It is stateless and privacy-respecting: nothing is stored. Feeds are fetched on demand, filtered, returned, and forgotten. No personal data is collected.
Related MCP server: Genius Sports RSS Monitor MCP
Reading feeds is easy; deciding what matters is the work. By exposing this as an MCP server, the filtering/dedup/recency logic runs deterministically in the tool, and the LLM (Claude, Cursor, Cline…) does what it is good at on top: summarising the digest, spotting themes, drafting an alert. The model never has to fetch or page through raw XML, and the same server works identically across every MCP client — so a "morning competitive brief" is one natural-language request away.
This is a tool server, not a CLI reader. It does not print feeds on its own. It exposes tools that an MCP client (Claude Code, Claude Desktop, Cursor, Cline) calls for you. You get RSS digests by connecting it to a client and asking in plain language — not by running a command here.
So the only required step is Configuration (connect it to your client). The steps below are an optional sanity check.
Requires Python ≥ 3.10; the client launches the server via
uv.
# (optional) clone + run the tests — stdlib only, no install, proves it works
git clone https://github.com/tefunamu/rss-digest-mcp.git
cd rss-digest-mcp
python3 -m unittest discover -s tests -v # 16 tests, expect "OK"You do not need to start the server by hand — your MCP client does that.
If you just want to confirm it boots, uvx --from . rss-digest-mcp will sit
silently waiting for a client to speak MCP over stdio (that silence is correct —
there is no output until a client calls a tool). Press Ctrl-C to stop.
Once connected (next section), ask your client something like:
"Use get_digest on
https://hnrss.org/frontpageandhttps://zenn.dev/feed, keywords AI, last 24 hours."
The server speaks MCP over stdio. Add one of the blocks below to your client, then ask: "Use get_digest on these feeds for the last 24h with keywords pricing, funding."
Use the absolute path to this repo in every example below. A wrong/relative path is the #1 reason the server silently fails to start.
Windows ARM64 users: install the package with the constraints file first — see Troubleshooting › Windows ARM64.
# from anywhere — register the server (use the absolute repo path)
claude mcp add rss-digest -- uvx --from /ABSOLUTE/PATH/TO/rss-digest-mcp rss-digest-mcp
# add -s user to make it available in every project:
# claude mcp add -s user rss-digest -- uvx --from /ABSOLUTE/PATH/TO/rss-digest-mcp rss-digest-mcp
claude mcp list # should show rss-digest: ✓ connectedThen in a new session: "Use get_digest on https://zenn.dev/feed, keywords AI, last 24h."
~/Library/Application Support/Claude/claude_desktop_config.json (macOS) /
%APPDATA%\Claude\claude_desktop_config.json (Windows):
{
"mcpServers": {
"rss-digest": {
"command": "uvx",
"args": ["--from", "/ABSOLUTE/PATH/TO/rss-digest-mcp", "rss-digest-mcp"]
}
}
}~/.cursor/mcp.json (or Settings → MCP → Add):
{
"mcpServers": {
"rss-digest": {
"command": "uvx",
"args": ["--from", "/ABSOLUTE/PATH/TO/rss-digest-mcp", "rss-digest-mcp"]
}
}
}cline_mcp_settings.json (Cline → MCP Servers → Configure):
{
"mcpServers": {
"rss-digest": {
"command": "uvx",
"args": ["--from", "/ABSOLUTE/PATH/TO/rss-digest-mcp", "rss-digest-mcp"],
"disabled": false
}
}
}What these tools are not:
get_digestis a deterministic filter over the feeds you give it — it matches keywords as plain substrings and sorts by recency. It does not search the web, and it does not infer which feeds a topic belongs to. Choosing the right feed URLs, turning a question into keywords, and judging whether a hit is actually relevant is the client's (the LLM's) job — the tool just fetches, filters and dedups. So "find what Japanese electronics makers said about pricing" only works if the client first supplies those makers' feed URLs and sensible keywords.
Tool | Arguments | Returns |
|
| Combined digest across all feeds: matched items (newest first, deduped by link), |
|
| Latest items of one feed (newest first), plus |
|
| Feed list ( |
Each returned item has: title, link, summary (HTML-stripped),
source (feed title), published (ISO-8601 UTC), published_ts (epoch).
Works with any RSS/Atom feed. feedparser decodes legacy Japanese encodings
(Shift_JIS / EUC-JP) transparently, so Japanese sources work out of the box:
Hacker News front page — https://hnrss.org/frontpage
NHK 主要ニュース — https://www.nhk.or.jp/rss/news/cat0.xml
Zenn (trending) — https://zenn.dev/feed
Qiita (popular) — https://qiita.com/popular-items/feed
GitHub repo releases — https://github.com/<owner>/<repo>/releases.atom
Once connected, you drive it in plain language — your MCP client turns the request into the right tool call. Examples (paste into Claude / Cursor / Cline):
Competitive / industry monitoring
Use
get_digestonhttps://hnrss.org/frontpageandhttps://techcrunch.com/feed/, keywordspricing, layoffs, funding, last 24 hours, then summarize the themes.
Japanese tech news, compact summaries
get_digestonhttps://zenn.dev/feedandhttps://qiita.com/popular-items/feed, keywordAI, last 24h,summary_max_chars200.
Just the latest from one source
fetch_feedhttps://news.ycombinator.com/rss, limit 10.
Onboard a feed list, then digest it
load_opml./feeds.opml, thenget_digeston those URLs with keywordAI.
A real run — 2 feeds, keyword AI, last 24h, summary_max_chars=200 — returns:
{
"count": 5,
"feeds_requested": 2,
"feeds_ok": 2,
"errors": [],
"items": [
{
"title": "OpenAI unveils its first custom chip, built by Broadcom",
"link": "https://techcrunch.com/2026/06/24/openai-unveils-its-first-custom-chip-built-by-broadcom/",
"summary": "Announcement: …",
"source": "Hacker News: Front Page",
"published": "2026-06-24T17:47:00Z",
"published_ts": 1782323220.0
}
// … 4 more, newest first, deduped across both feeds
]
}The client (the LLM) chooses the feeds + keywords and reads this back to you as a brief; the tool just fetches, filters and dedups.
MCP client (Claude Desktop / Cursor / Cline)
│ stdio (MCP)
▼
server.py ── FastMCP tools: get_digest / fetch_feed / load_opml
│ │
│ └─ feedparser → fetch + parse RSS/Atom/JSON (handles JP encodings)
▼
core.py ── pure, stdlib-only logic: recency filter · keyword match ·
dedup-by-link · newest-first sort · capThe split is deliberate: core.py has zero third-party imports, so the
business logic is fully unit-tested without the network or the MCP SDK
(server.py is the thin I/O shell). Stateless by design — no storage layer.
python3 -m unittest discover -s tests -vThe suite covers HTML cleaning, UTC timestamp handling, keyword matching, the recency window (including undated items), and the dedup/sort/cap pipeline — all with a fixed clock for determinism.
The launch command isn't runnable. Either install uv (pip install uv) so
uvx works, or use the no-uv path: pip install -e . then register the server
as python -m rss_digest_mcp. After changing the client config, start a new
session — existing sessions don't pick up new servers.
cryptography fails to build / uvx won't connectOn native win-arm64, cryptography ≥ 47 ships no prebuilt wheel, so pip
falls back to a Rust source build that needs MSVC link.exe and fails on a clean
machine (cryptography arrives transitively via the MCP SDK → pyjwt[crypto]).
The uvx --from . launch in Configuration also fails here,
because uvx builds the package in a fresh isolated env and ignores the
constraints file, re-triggering that same source build.
Use the pip + python -m path instead:
# 1. install, pinned to cryptography's last win-arm64 wheel (46.0.3)
python -m pip install -e . -c constraints-winarm64.txt --only-binary=cryptography
# 2. register with the module launcher (NOT uvx)
claude mcp add -s user rss-digest -- python -m rss_digest_mcp
claude mcp list # rss-digest ... ✓ connectedNotes:
The pin is environment-specific — x64 / macOS / Linux have current wheels —
so it lives in constraints-winarm64.txt, not
in pyproject.toml (which would needlessly hold those platforms back).
claude mcp add records the absolute path of the python you used. If you
later move or replace that interpreter, re-run claude mcp add.
If you must keep using uvx, pass the constraints via the UV_CONSTRAINT
environment variable — but that still rebuilds the isolated env, so the direct
python -m launch is lighter and more reliable.
MIT — see LICENSE.
Fetch a single RSS/Atom feed and return its latest items (newest first).
summary_max_chars optionally shortens each summary (default 0 = full).
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | ||
| limit | No | ||
| summary_max_chars | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses that results are ordered newest first and that summary_max_chars can shorten summaries. However, lacks details on caching, error behavior, or rate limits. With no annotations, description carries full burden but is only partially transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: first clearly states purpose, second adds parameter detail. No filler words. Efficient and well-structured.
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?
No output schema exists; description only vaguely mentions 'items' without specifying structure. No error handling or edge case info. Leaves significant gaps for a tool with 3 parameters.
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 0%, so description must compensate. It explains summary_max_chars behavior and default, but does not elaborate on url or limit beyond schema basics. Provides some value but not comprehensive.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Fetch' and the resource 'RSS/Atom feed', and specifies 'latest items (newest first)'. This distinguishes the tool from siblings like 'get_digest' and 'load_opml'.
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. No context about prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Build one competitive-intelligence digest across many RSS/Atom feeds.
Args: feeds: RSS/Atom feed URLs to pull from (competitor blogs, news, jobs…). keywords: only keep items whose title/summary contains one of these (case-insensitive). Omit or pass [] to get everything recent. hours: only keep items published within the last N hours (default 24). Undated items are kept. Pass 0 to disable the time filter. max_items: cap on returned items after dedup + sort (default 30). summary_max_chars: optionally shorten each item's summary to this many characters (with an ellipsis) to keep the digest compact. Default 0 = no truncation (full summaries).
Returns a dict with the matched items (newest first, deduped by link),
a count, how many feeds succeeded, and any per-feed errors.
| Name | Required | Description | Default |
|---|---|---|---|
| feeds | Yes | ||
| keywords | No | ||
| hours | No | ||
| max_items | No | ||
| summary_max_chars | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite no annotations being provided, the description covers key behaviors: deduplication by link, sorting by newest first, handling of undated items, truncation of summaries, and the structure of the returned dict. It also explains default values and edge cases (e.g., pass 0 to disable time filter). The description provides sufficient transparency for a read-only aggregation 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?
The description is well-structured with a clear opening line, a labeled 'Args' section, and a final sentence describing the return value. It uses a consistent format and avoids unnecessary words. However, it could be slightly more concise by consolidating some parameter details (e.g., default values are already in the schema).
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 complexity (5 parameters, no output schema, no annotations), the description is fairly complete. It explains return value structure ('items', 'count', success count, 'errors') and covers key edge cases (undated items, dedup, sorting). It does not provide example output or error handling beyond per-feed errors, but it is sufficient for most use cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, so the description carries the full burden. It explains each parameter's purpose and behavior: 'feeds' (RSS/Atom URLs with examples), 'keywords' (case-insensitive filtering, behavior when omitted), 'hours' (time filter with undated items handling), 'max_items' (cap after dedup+sort), and 'summary_max_chars' (truncation with ellipsis). This adds substantial meaning beyond the schema's basic titles and types.
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 builds a competitive-intelligence digest from multiple RSS/Atom feeds, specifying the action (build a digest) and the resource (feeds). It implicitly distinguishes from siblings 'fetch_feed' (single feed) and 'load_opml' (import OPML) by focusing on aggregation and filtering.
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 explains the parameters and their defaults, which implies usage scenarios (e.g., filtering by keywords, time range). However, it does not explicitly state when to use this tool versus alternatives like 'fetch_feed' or 'load_opml', nor does it provide when-not-to-use guidance. 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.
Read a local OPML file and return the feed list (title + xmlUrl).
Use this to bulk-onboard a feed collection exported from another reader,
then pass the URLs to get_digest. Only reads the file you point at.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must carry full burden. It discloses read-only nature and local file access. Could mention validation or error behavior, but sufficiently transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, front-loaded with purpose, no wasted words. Efficient structure.
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?
Adequate for a simple tool: covers purpose, usage, and read-only behavior. Missing return format details but partly addressed by listing feed title and xmlUrl.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% and description does not elaborate on the path parameter beyond implying it's a file path. No format, requirements, or constraints added.
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 reads a local OPML file and returns the feed list with title and xmlUrl. It distinguishes from siblings like fetch_feed and get_digest.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly advises to use for bulk-onboarding from OPML exports and then pass URLs to get_digest. Provides clear when-to-use context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.1.0fetch_feedget_digestload_opmlEach tool has a clear, distinct purpose: fetch_feed for a single feed, get_digest for aggregated multi-feed digests with filtering, and load_opml for importing feed lists. No overlap or ambiguity.
All tool names follow the verb_noun pattern with lowercase underscores (fetch_feed, get_digest, load_opml), providing a predictable and consistent naming convention.
With 3 tools, the server is well-scoped for its purpose of RSS feed digestion. Each tool fills a necessary role without being too few or too many.
The tools cover the full workflow: loading feeds (load_opml), fetching a single feed (fetch_feed), and building a filtered digest across multiple feeds (get_digest). No obvious gaps for the stated competitive-intelligence digest purpose.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Read, search and track your RSS feeds: semantic search, story clustering, watches, OPML import.
Search bounded RSS, Atom, and RDF feed matches by keyword or regex.
Intelligence subscription protocol for AI agents. Scored, filtered AI intelligence signals via MCP.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/tefunamu/rss-digest-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
