Provides tools to fetch, search, and filter RSS blog feeds from configured categories and sources.
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 Feeds MCP Server fetch the latest marketing blogs"
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.
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-mcp-marketing
Do all of the following:
1. Clone the repo into a sensible folder (e.g. ~/mcp-servers/rss-mcp-marketing) 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: MCP RSS
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 |
|---|---|---|---|
| url | Yes | RSS feed URL | |
| name | Yes | Name for the feed (e.g., 'techcrunch') | |
| category | No | Category: seo, content, social, email, analytics, crm, news |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must fully disclose behavioral traits. It only states the action and optionality of category, omitting side effects (e.g., duplicate handling, validation, or persistence). This is insufficient for an agent to understand the tool's full implications.
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?
A single sentence with no extraneous content. Every word serves a purpose, and the message is front-loaded.
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 creation tool with clear schema and no output schema, the description covers the core action. However, it lacks behavioral details (error states, idempotency) that would help an agent in complex workflows, making it adequate but not thorough.
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 descriptions for all three parameters. The description redundantly confirms category is optional but adds no new meaning beyond the schema. 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?
The description uses a specific verb ('Add') and resource ('RSS feed'), clearly stating the action. It mentions the optional category. However, it does not differentiate from sibling tools like 'fetch_blogs' or 'list_feeds', missing explicit distinction.
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 given on when to use this tool versus alternatives (e.g., when to add vs. fetch or list). The agent is left to infer usage without context about prerequisites or fallbacks.
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 |
|---|---|---|---|
| limit | No | Maximum number of articles to return (default: 20) | |
| range | No | Date range: '1d', '7d', '1w', '30d', '1m', 'this_week', 'this_month' (default: 7d) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must disclose behavioral traits. It only mentions basic filtering without details on ordering, pagination, or whether full content is returned. This is insufficient for a fetch operation.
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?
A single sentence of 12 words that front-loads the core purpose ('Fetch latest blogs'). Every word is necessary, and the structure optimizes for quick scanning.
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 tool with 2 optional parameters and no output schema, the description covers scope but omits return format or behavioral details. It is adequate but not thorough.
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 adequate descriptions for both parameters. The description adds no extra meaning beyond the schema, so it meets the baseline for this dimension.
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 ('Fetch'), the resource ('latest blogs from all feeds'), and the filtering options ('date range and limit'). This effectively distinguishes it from sibling tools like fetch_by_category and 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 explicit guidance on when to use this tool versus alternatives. Given the presence of sibling tools (e.g., fetch_by_category, search_blogs), the description lacks instructions on preferred use cases.
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 |
|---|---|---|---|
| limit | No | Maximum number of articles to return (default: 20) | |
| range | No | Date range: '1d', '7d', '1w', '30d', '1m' (default: 7d) | |
| category | Yes | Category to filter by: seo, content, social, email, analytics, crm, news |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It lists categories but does not disclose ordering, pagination, rate limits, or what happens on invalid category.
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, concise and front-loaded. Could use structured format (e.g., bullet points) but no waste.
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, no annotations. Description omits details like default limit, ordering, error handling. For a fetch tool with 3 params, more context needed.
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 covers all 3 parameters with descriptions (100% coverage), so baseline is 3. Description adds no new info on parameters beyond the schema.
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?
Verb 'Fetch' and resource 'blogs from a specific category' are clear. Lists allowed categories. Distinguishes from sibling fetch_tools like fetch_blogs (all) and fetch_from_source (by 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?
Implies usage when filtering by category, but no explicit when-to-use or when-not-to-use compared to siblings like search_blogs or list_categories.
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 | |
| limit | No | Maximum number of articles to return (default: 20) | |
| range | No | Date range: '1d', '7d', '1w', '30d', '1m' (default: 7d) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are absent, so the description carries the full burden. It only states the action without disclosing any side effects, safety profile, rate limits, or output characteristics. For a read-like operation, minimal transparency is acceptable but insufficient.
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 and front-loaded. However, it is too brief and omits important details, making it underinformative. A higher score would require more substance without verbosity.
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 three parameters, no output schema, and no annotations, the description is insufficient for an agent to fully understand the tool. It does not explain what constitutes a 'source', return format, or pagination behavior. The minimal description leaves significant gaps.
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 covers all three parameters with descriptions (name, limit, range), achieving 100% schema coverage. The tool description adds no further meaning about parameters or their usage, so a baseline score of 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?
The description 'Fetch blogs from a specific source' clearly indicates the action (fetch) and resource (blogs) with a specific source. However, it does not differentiate from sibling 'fetch_blogs', which lacks the 'from source' qualifier. A higher score would require explicit sibling differentiation.
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 fetch_blogs, fetch_by_category, or search_blogs. There is no mention of prerequisites, constraints, or typical use cases.
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?
No annotations are provided, and the description does not disclose behavioral traits such as read-only nature, return format, or any constraints. It minimally implies a read operation but lacks detail.
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 of 8 words, front-loaded with the action and resource. Every word is meaningful with no redundancy.
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 list tool with no output schema, the description is minimally adequate but could be improved by specifying the output format (e.g., 'returns list of category names'). It meets basic needs but lacks 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?
With no parameters, the description adds value by explaining the tool's purpose beyond the empty schema. Schema description coverage is 100%, and the description effectively communicates what is returned.
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 'List all available feed categories for organizing content' uses a specific verb ('list') and resource ('categories'), clearly distinguishing it from siblings like 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 is provided on when to use this tool versus alternatives, nor any exclusions or prerequisites. The description is too brief to convey usage context.
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?
With no annotations, the description must convey behavior. It correctly implies read-only ('list'), but lacks details on authentication, pagination, or any constraints. Adequate but minimal.
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?
A single sentence that is concise and front-loaded with the essential action and scope. No unnecessary words.
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 zero-parameter tool with no output schema, the description provides sufficient information. It could mention ordering or inclusion of categories, but overall complete.
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 parameters, so schema coverage is 100%. The description adds no parameter info but also doesn't need to. Baseline 4 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 states 'List all configured RSS feeds with their categories', which clearly specifies the verb (list) and the resource (RSS feeds) and distinguishes from sibling tool 'list_categories'.
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 vs alternatives like 'list_categories' or 'search_blogs'. No exclusionary criteria or context provided.
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?
No annotations exist, so the description carries full burden. 'Remove' implies a destructive operation, but no details on permanence, side effects, or required permissions are given.
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, no wasted words. However, could be structured with more details (e.g., bullet points) without harming conciseness.
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 or return value description. The tool performs a destructive action but lacks information about success confirmation or error scenarios.
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% (parameter with description), so baseline is 3. The description adds 'by name' but does not provide additional semantic value beyond the schema.
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 'Remove' and the resource 'RSS feed', and specifies the identifier 'by name'. It distinguishes well from sibling tools like '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 provided on when to use this tool versus alternatives, e.g., listing feeds first or confirming deletion. The description lacks preconditions or postconditions.
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 |
|---|---|---|---|
| limit | No | Maximum number of articles to return (default: 20) | |
| range | No | Date range: '1d', '7d', '1w', '30d', '1m' (default: 30d) | |
| keyword | Yes | Keyword or phrase to search for (e.g., 'email marketing', 'AI', 'SEO tips') |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It implies a read operation ('search') but does not disclose any behavioral traits such as rate limits, authentication needs, or response structure. A score of 3 reflects that it is minimally adequate but lacks depth.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single well-structured sentence. Every word adds value—no fluff, no repetition, and it is front-loaded with the key action.
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 absence of an output schema and the presence of sibling tools, the description is fairly complete. It explains the tool's purpose and provides a use case. However, it could be improved by noting that results are articles or mentioning any limits (e.g., max results).
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%, meaning the input schema already describes all three parameters (keyword, limit, range). The description does not add any additional meaning beyond what is in the schema, so a baseline of 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?
The description clearly states the action ('Search'), the resource ('blogs'), and the scope ('across all feeds'). It is specific and distinguishes from sibling tools like list_categories or 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?
The description provides a use case ('great for finding content ideas on specific topics'), indicating when to use it, but does not explicitly mention when not to use it or compare with alternatives like fetch_blogs or fetch_by_category.
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.
v2.0.0add_feedfetch_blogsfetch_by_categoryfetch_from_sourcelist_categorieslist_feedsremove_feedsearch_blogsScored across 8 tools
Tools are largely distinct, but fetch_blogs, fetch_by_category, and fetch_from_source have overlapping functionality; descriptions help differentiate them.
All tool names follow a consistent verb_noun pattern (list_, add_, remove_, fetch_, search_), making them predictable.
8 tools is well-scoped for an RSS feed management server; enough to cover core operations without being overwhelming.
Missing update feed and category management tools (add/remove categories); fetch operations support basic retrieval but lack feed refresh.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
SEO, competitor and AI-search data, plus blog management — draft, schedule and publish posts.
Track and browse RSS feeds with ease. Fetch the latest entries from any feed URL and extract full…
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.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/lionkiii/rss-mcp-marketing'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
