Skip to main content
Glama
kwp-lab

rss-reader-mcp

by kwp-lab
OverviewSchemaRelated ServersScoreDiscussions
JavaScript
Remote

RSS Reader MCP

An MCP (Model Context Protocol) server for RSS feed aggregation and article content extraction. You can use it to subscribe to RSS feeds and get article lists, or extract the full content of an article from a URL and format it as Markdown.

English | δΈ­ζ–‡

npm version license build status

πŸš€ Quick Start

You can use this MCP server in MCP-capable clients such as Claude Desktop and CherryStudio.

Claude Desktop

For Claude Desktop, add the following configuration under the "mcpServers" section in your claude_desktop_config.json file:

{
  "mcpServers": {
    "rss-reader": {
      "command": "npx",
      "args": [
        "-y",
        "rss-reader-mcp"
      ]
    }
  }
}

Usage Examples

Related MCP server: rss-mcp

πŸ”§ Tools Reference

fetch_feed_entries

Fetch RSS entries from a specified URL

Parameters:

  • url (required string): RSS feed URL

  • limit (optional number): Maximum number of entries to return (default 10, max 100)

Returns: A JSON object containing feed metadata and a list of entries (including title, link, publication date, and summary)

fetch_article_content

Extract article content from a URL and format it as Markdown

Parameters:

  • url (required string): Article URL

Returns: A JSON object containing the title, Markdown content, source URL, and timestamp

βš™οΈ Transport & Environment Variables

This server supports two transport modes:

  • stdio (default): Communicates via standard input/output. Suitable for clients that run a local process, such as Claude Desktop.

  • httpStream: Communicates over HTTP streaming. Suitable for clients that support HTTP(S) transport or for containerized deployments.

Available environment variables:

  • TRANSPORT: Select the transport mode, either stdio (default) or httpStream.

  • PORT: When TRANSPORT=httpStream, the listening port (default 8081).

  • MCP_SERVER_HOST: When TRANSPORT=httpStream, the listening address (default localhost). In Docker, set this to 0.0.0.0 to expose the port externally.

How to switch transport modes:

  • Using stdio (no extra setup, default):

    • Works with Claude Desktop via the command + args configuration (see example above).

  • Using httpStream:

    • Set the environment variable TRANSPORT=httpStream and specify PORT (defaults to 8081 if not set).

    • When running in a container, also set MCP_SERVER_HOST=0.0.0.0 and map the port.

    • The Dockerfile in this repository already includes related environment variable settings.

Docker Deployment

You can also run this MCP server in a Docker container. First, build the image in the project root:

docker build -t rss-reader-mcp .

Using CherryStudio as an example, the following configuration shows how to run this server over HTTP:

{
  "mcpServers": {
    "rss-reader-mcp": {
      "command": "docker",
      "args": [
        "run",
        "--rm",
        "-p",
        "8081:8081",
        "-e",
        "PORT=8081",
        "rss-reader-mcp"
      ]
    }
  }
}

Some RSS Feeds for Testing

  • BBC News: https://feeds.bbci.co.uk/news/rss.xml

  • TechCrunch: https://techcrunch.com/feed/

  • Hacker News: https://hnrss.org/frontpage

  • MIT Technology Review: https://www.technologyreview.com/feed/

Available Tools

2 tools
fetch_article_contentA
Read-onlyIdempotent
Inspect

Fetch and extract article content from a URL, formatted as Markdown

ParametersJSON Schema
NameRequiredDescriptionDefault
urlYes

TDQS

A3.9/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint, idempotentHint, and openWorldHint. The description adds that output is Markdown formatted, which is beyond what annotations provide. No behavioral contradictions are present.

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 of 12 words, front-loaded with the key action 'Fetch and extract', and contains no superfluous information.

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 the tool's simplicity (one parameter, no output schema, and comprehensive annotations), the description provides enough context: it specifies the action, resource, and output format. However, it could mention the return structure or error handling for full completeness.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0% schema description coverage, the description does not add significant meaning to the 'url' parameter beyond the schema's format: uri constraint. It only mentions 'from a URL', which is minimal additional context.

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 uses the verb 'Fetch and extract' with the resource 'article content' and specifies the output format 'Markdown'. It distinguishes itself from the sibling tool 'fetch_feed_entries', which likely fetches lists of entries rather than individual article content.

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?

The description implies usage for extracting article content from a URL but does not explicitly state when not to use it or provide guidance on choosing between this tool and the sibling 'fetch_feed_entries'.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

fetch_feed_entriesC
Read-onlyIdempotent
Inspect

Fetch RSS feed entries from a given URL

ParametersJSON Schema
NameRequiredDescriptionDefault
urlYes
limitNo

TDQS

C2.9/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint, idempotentHint, and openWorldHint. The description adds minimal behavioral context (fetching from URL), which is already implied by the input schema. No contradictions.

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, well-formed sentence with no fluff. It front-loads the key action and resource. Could be slightly improved with more detail, but remains concise.

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?

No output schema exists, so the description should explain the return value (e.g., list of entries with fields). It does not. Annotations cover safety but not functional completeness. The sibling tool is named but no usage differentiation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%. The description hints at the 'url' parameter ('from a given URL') but does not explain the 'limit' parameter or its purpose (e.g., max number of entries). The description adds insufficient meaning beyond the schema.

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 verb (Fetch) and resource (RSS feed entries) with a source URL. It distinguishes from the sibling tool 'fetch_article_content' by focusing on feed entries rather than individual article content.

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 vs. the sibling tool. Does not specify prerequisites or contexts where fetching feed entries is appropriate or inappropriate.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

B3.2/5.0
Disambiguation5/5

The two tools have clearly distinct purposes: one fetches a list of feed entries, the other fetches the full content of a single article. There is no overlap.

Naming Consistency5/5

Both tools use a consistent verb_noun pattern with 'fetch_' prefix, making them predictable and easy to understand.

Tool Count2/5

With only two tools, the server feels very thin for an 'rss-reader' purpose. A typical reader would include tools for managing feeds, subscriptions, or browsing, making this count too low.

Completeness1/5

The tool set is severely incomplete. There are no tools for feed management (e.g., add, list, remove feeds), no search or filter capabilities, and no persistence. The server cannot function as a full RSS reader.

Maintenance

ActivityInactive
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

  • Conduit

    Stefan0x03
    F
    license
    Not graded
    quality
    D
    maintenance
    A self-hosted RSS reader MCP server that manages RSS subscriptions and fetches live feed content, deployable on AWS.

  • rss-mcp

    jeffgbradley2
    A
    license
    B
    quality
    D
    maintenance
    An MCP server that provides RSS feed tools for Claude Desktop, enabling fetching and parsing RSS feeds with configurable feeds and blocklists.
    6
    MIT

  • junk-filter-mcp

    xiaoyu-ops
    A
    license
    Not graded
    quality
    C
    maintenance
    An MCP server that provides RSS feed management and LLM-powered article evaluation, enabling AI agents to filter and assess content value.
    MIT

  • simply-feed-mcp

    hmmroger
    A
    license
    A
    quality
    A
    maintenance
    An MCP server for managing and querying RSS/news feeds, enabling real-time fetching, searching, and retrieval of feed items.
    5
    25
    1
    MIT

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/kwp-lab/rss-reader-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server