This MCP server lets you manage and query RSS feeds, primarily designed for digital marketers to monitor content across multiple sources.
Feed Management
List categories — View available categories (seo, content, social, email, analytics, crm, news)
List feeds — See all configured RSS feeds and their categories
Add feed — Add a new RSS feed by providing a name, URL, and optional category
Remove feed — Remove an existing feed by name
Content Fetching & Discovery
Fetch blogs — Retrieve the latest posts across all feeds, with optional date range and result limit (default: 20)
Fetch by category — Filter posts by a specific category (e.g. only SEO or email feeds)
Fetch from source — Pull posts from a single named feed
Search blogs — Keyword search across all feeds (e.g. "AI", "email marketing")
Supported date ranges: 1d, 7d, 1w, 30d, 1m, this_week, this_month. Feed data persists in feeds.json and can be managed via tools or direct file editing.
Enables monitoring and fetching the latest blog posts from HubSpot to track content marketing trends and updates.
Provides tools to fetch, filter, and search RSS feeds from various sources to monitor blogs, track industry news, and research content.
Allows for fetching and searching the latest technology news and articles directly from TechCrunch's RSS feed.
An MCP server for digital marketers to fetch, search, and filter RSS blog feeds. Works with Claude Desktop and any MCP-compatible client.
Open Claude Code in your terminal and paste the prompt below. It clones this repo, builds it, and wires it into Claude Desktop for you.
Set up this RSS MCP server for my Claude Desktop.
Repo: https://github.com/lionkiii/rss-feeds-mcp
Do all of the following:
1. Clone the repo into a sensible folder (e.g. ~/mcp-servers/rss-feeds-mcp) if it isn't already cloned, then cd into it.
2. Run `npm install` and `npm run build`. Confirm `dist/index.js` exists.
3. Find the absolute path to my node binary (`which node`; if it is under nvm use that full path, because Claude Desktop does not load my shell PATH).
4. Locate my Claude Desktop config:
- macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
- Windows: %APPDATA%\Claude\claude_desktop_config.json
Create the file with `{}` if it does not exist. Back it up first.
5. IMPORTANT: fully quit Claude Desktop before editing the config, because a running Claude Desktop rewrites the file on write and will discard my changes. On macOS quit it with `osascript -e 'tell application "Claude" to quit'`.
6. Merge (do not overwrite) an "mcpServers" entry named "rss-feeds" whose "command" is my absolute node path and whose "args" is the absolute path to dist/index.js. Keep the JSON valid and preserve any existing config keys and other mcpServers.
7. Relaunch Claude Desktop and verify the config still contains the rss-feeds entry after launch, and that a node process running dist/index.js was spawned.
8. Tell me to try: "fetch the latest marketing blogs".Related MCP server: RSS-MCP
list_categories - list feed categories
list_feeds - list configured feeds
add_feed - add a feed (name, url, category)
remove_feed - remove a feed by name
fetch_blogs - latest posts across all feeds (range, limit)
fetch_by_category - posts filtered by category
fetch_from_source - posts from one source
search_blogs - keyword search across all feeds
Date ranges: 1d, 7d, 1w, 30d, 1m, this_week, this_month.
npm install
npm run buildConfig file (macOS):
~/Library/Application Support/Claude/claude_desktop_config.json
{
"mcpServers": {
"rss-feeds": {
"command": "node",
"args": ["/absolute/path/to/RSS/dist/index.js"]
}
}
}Notes:
Use an absolute path to dist/index.js.
If node is installed via nvm, use the absolute node path (e.g.
~/.nvm/versions/node/<version>/bin/node) because Claude Desktop does not
load your shell PATH.
Run npm run build after editing src/index.ts, then restart Claude Desktop.
Feeds live in feeds.json. Edit directly or use the add_feed / remove_feed
tools. All feed requests use a browser User-Agent and a 20s hard timeout so a
slow or dead feed can never hang the whole request.
Add a new RSS feed with optional category
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Name for the feed (e.g., 'techcrunch') | |
| url | Yes | RSS feed URL | |
| category | No | Category: seo, content, social, email, analytics, crm, news |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Fails to disclose non-idempotent behavior (risk of duplicate feeds) or whether URL validation occurs, adding nothing beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely terse (9 words) but front-loaded; lacks secondary sentence for behavioral context but avoids fluff.
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?
Minimal but acceptable for low complexity; missing explanation of return value or success confirmation due to absent output schema.
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 has 100% description coverage; description reinforces optional nature of category but adds no new semantic meaning.
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?
Clear verb ('Add') and resource ('RSS feed') with mention of optional category, though doesn't differentiate from sibling fetch_from_source.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this vs fetch_from_source or whether to check list_feeds first to avoid duplicates.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch latest blogs from all feeds with date range and limit
| Name | Required | Description | Default |
|---|---|---|---|
| range | No | Date range: '1d', '7d', '1w', '30d', '1m', 'this_week', 'this_month' (default: 7d) | |
| limit | No | Maximum number of articles to return (default: 20) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No contradictions with annotations, but adds no behavioral context beyond what readOnly/idempotent hints already provide.
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 and front-loaded, though arguably too terse to convey differentiating value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequate for simple tool but lacks output description (no output schema exists) and sibling differentiation guidance.
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 has 100% coverage; description merely repeats that range and limit exist without adding semantic context.
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?
States specific action (fetch) and scope (all feeds), distinguishing from fetch_by_category and fetch_from_source, though unclear how it differs from search_blogs.
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 versus fetch_by_category, fetch_from_source, or search_blogs.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch blogs from a specific category (seo, content, social, email, analytics, crm, news)
| Name | Required | Description | Default |
|---|---|---|---|
| category | Yes | Category to filter by: seo, content, social, email, analytics, crm, news | |
| range | No | Date range: '1d', '7d', '1w', '30d', '1m' (default: 7d) | |
| limit | No | Maximum number of articles to return (default: 20) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds no behavioral context beyond what annotations already provide (read-only, idempotent); does not disclose return format or rate limits despite no output schema.
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 is appropriately front-loaded and concise, though minimal content leaves informational gaps.
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?
Lacks return value description despite no output schema; missing usage context that would help select between similar fetch tools.
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 has 100% description coverage; description redundantly lists category enum values already present in schema without adding semantic context.
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?
Clear verb (fetch) and resource (blogs), distinguishes from siblings by specifying 'specific category' and listing valid category values.
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 versus fetch_blogs, fetch_from_source, or search_blogs; no exclusions or alternatives mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch blogs from a specific source
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Name of the feed source | |
| range | No | Date range: '1d', '7d', '1w', '30d', '1m' (default: 7d) | |
| limit | No | Maximum number of articles to return (default: 20) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations fully cover behavior (readOnly, idempotent, openWorld); description adds no new behavioral context but does not contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise (6 words) but too terse for the complexity of the tool suite; lacks necessary differentiating context despite brevity.
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?
Insufficient given 7 sibling tools with overlapping functionality; fails to clarify the feed/source selection use case despite requiring specific source names.
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 has 100% description coverage with clear parameter semantics; description adds nothing but baseline is 3 per rules for high schema coverage.
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?
States basic action (fetch blogs) but 'specific source' is vague and fails to distinguish from sibling 'fetch_blogs' or clarify what constitutes a source.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides no guidance on when to use this tool versus 'fetch_blogs', 'fetch_by_category', or 'search_blogs'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all available feed categories for organizing content
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds minimal context ('for organizing content') but provides no behavioral details beyond annotations (e.g., whether categories are user-defined or system-defined, cached vs. live).
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, front-loaded sentence with no redundancy; appropriate length for tool complexity.
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?
Lacks description of return structure despite absent output schema; misses opportunity to explain relationship to sibling 'fetch_by_category' given category values are likely inputs there.
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?
Zero parameters present, meeting the baseline expectation; no additional parameter semantics needed.
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?
Clear verb ('List') and resource ('feed categories') with purpose clause ('for organizing content'), implicitly distinguishing from 'list_feeds' though explicit sibling contrast would strengthen it further.
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 versus alternatives (e.g., 'use before fetch_by_category to discover valid values') or when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all configured RSS feeds with their categories
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds 'configured' (implying persistence) and 'with their categories' (structural hint) beyond annotations, but misses opportunity to clarify return format or pagination behavior.
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 front-loaded sentence with strong verb; no fluff given the tool's simplicity and zero-parameter 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?
Mentions categories which aids understanding, but lacks return value description despite absence of output schema; adequate but not comprehensive for the sibling complexity.
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?
Zero parameters present triggers baseline 4; description appropriately omits parameter discussion as none exist.
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?
Clear verb ('List') and resource ('configured RSS feeds'), with 'configured' effectively distinguishing from fetch siblings, though explicit differentiation from list_categories is absent.
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?
Usage is implied by the listing purpose, but lacks explicit guidance on when to use versus fetch_blogs or list_categories, and omits 'when-not' scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Remove an RSS feed by name
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Name of the feed to remove |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds no behavioral context beyond annotations (destructive/idempotent nature not mentioned in text).
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 brief (5 words) and front-loaded, though arguably too minimal for a destructive operation.
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 single-parameter tool, but lacks any mention of the destructive consequences despite annotation hint.
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 has 100% coverage; description only echoes 'by name' without adding semantic nuance.
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?
Specific verb ('Remove') and resource ('RSS feed') clearly stated, and implicitly distinguishes from sibling 'add_feed' and 'list_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 on when to use versus alternatives or when removal is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search blogs by keyword across all feeds - great for finding content ideas on specific topics
| Name | Required | Description | Default |
|---|---|---|---|
| keyword | Yes | Keyword or phrase to search for (e.g., 'email marketing', 'AI', 'SEO tips') | |
| range | No | Date range: '1d', '7d', '1w', '30d', '1m' (default: 30d) | |
| limit | No | Maximum number of articles to return (default: 20) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds scope context ('across all feeds') beyond annotations, though omits return format details and rate limiting since annotations cover safety/read-only traits.
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 well-structured sentence with purpose front-loaded and benefit clause appended; no fluff but could use punctuation to separate clauses.
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 basic invocation but lacks description of return values since no output schema exists (only hint is 'content ideas' and schema's 'articles' reference).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with clear examples; description relies on schema without adding redundant parameter guidance, meeting baseline.
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?
Clear verb ('Search') + resource ('blogs across all feeds') with explicit keyword mechanism that distinguishes from fetch-by-category or list operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides one use case ('finding content ideas') but lacks explicit when-not-to-use guidance or comparison to fetch_blogs/fetch_from_source alternatives.
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.
v1.0.2add_feedfetch_blogsfetch_by_categoryfetch_from_sourcelist_categorieslist_feedsremove_feedsearch_blogsEach fetch operation has a clearly distinct filtering mechanism—date range for fetch_blogs, category for fetch_by_category, specific source for fetch_from_source, and keyword for search_blogs. Feed management tools (add, list, remove) target different lifecycle stages without overlap.
Most tools follow a clear verb_noun pattern (add_feed, list_feeds, search_blogs). The fetch operations slightly deviate with prepositions (fetch_by_category, fetch_from_source) but remain consistent with each other and readable.
Eight tools provides excellent coverage for RSS management without bloat. The set includes feed CRUD operations (minus update), multiple retrieval strategies, and category management—appropriate scope for an RSS server.
Covers core RSS workflows well: adding/removing feeds, listing metadata, and retrieving content via multiple filters. Minor gap in missing update_feed operation (for changing categories or URLs), though agents can work around this via remove/add sequence.
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.
AI-powered news intelligence — 21 tools for personalized monitoring, briefings, and semantic search
Track and browse RSS feeds with ease. Fetch the latest entries from any feed URL and extract full…
SEO, competitor and AI-search data, plus blog management — draft, schedule and publish posts.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/lionkiii/rss-feeds-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
