Skip to main content
Glama
panxiande

RSSHub MCP Server

by panxiande
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Local

RSSHub MCP Server

中文文档 | English

一个用于 RSSHub 的 Model Context Protocol (MCP) 服务器，让 AI 助手能够通过 MCP 协议访问和查询各种 RSS 订阅源。

功能特性

  • 🔍 RSS 订阅获取：通过路由获取各种网站的 RSS feed

  • ⭐ 订阅管理（新功能）：

    • 添加/删除订阅源

    • 一键获取所有订阅内容

    • 本地持久化存储订阅列表

    • 为每个订阅设置默认参数和自定义名称

  • 🔎 智能路由搜索：从 RSSHub API 自动获取所有可用路由并支持模糊搜索

  • 💾 路由缓存：自动缓存路由数据（24小时），提升响应速度

  • ⚙️ 灵活实例配置：

    • 支持环境变量 RSSHUB_INSTANCE 配置自定义实例

    • 支持参数方式临时指定实例

    • 默认使用公共实例 https://rsshub.app

  • 🎯 通用参数支持：过滤、限制条目数、全文输出等

  • 🌐 完整平台覆盖：覆盖所有 RSSHub 支持的平台和路由

  • ⏱️ 智能超时处理：60 秒超时，支持处理复杂路由

  • 🔧 详细错误诊断：针对不同错误类型提供具体的解决建议

  • 📊 请求日志：记录请求 URL、耗时和详细错误信息

  • 🚀 轻量级：仅 40 个依赖包，快速安装和启动

Related MCP server: MCP-RSS-Crawler

安装

方式 1：通过 npx（推荐）

无需手动安装，直接在 Claude Desktop 配置中使用 npx 即可：

编辑配置文件：

  • macOS: ~/Library/Application Support/Claude/claude_desktop_config.json

  • Windows: %APPDATA%\Claude\claude_desktop_config.json

{
  "mcpServers": {
    "rsshub": {
      "command": "npx",
      "args": ["rsshub-mcp"]
    }
  }
}

如需使用自定义 RSSHub 实例：

{
  "mcpServers": {
    "rsshub": {
      "command": "npx",
      "args": ["rsshub-mcp"],
      "env": {
        "RSSHUB_INSTANCE": "http://localhost:1200"
      }
    }
  }
}

方式 2：从源码构建

# 克隆仓库
git clone https://github.com/panxiande/RSSHub-MCP.git
cd RSSHub-MCP

# 安装依赖
npm install

# 构建项目
npm run build

然后在 Claude Desktop 配置文件中添加：

macOS

{
  "mcpServers": {
    "rsshub": {
      "command": "node",
      "args": ["/path/to/RSSHub-MCP/dist/index.js"]
    }
  }
}

Windows

{
  "mcpServers": {
    "rsshub": {
      "command": "node",
      "args": ["C:\\path\\to\\RSSHub-MCP\\dist\\index.js"]
    }
  }
}

使用自定义实例（推荐）

通过环境变量 RSSHUB_INSTANCE 指定自定义实例，获得更好的稳定性：

{
  "mcpServers": {
    "rsshub": {
      "command": "npx",
      "args": ["rsshub-mcp"],
      "env": {
        "RSSHUB_INSTANCE": "http://localhost:1200"
      }
    }
  }
}

配置完成后，重启 Claude Desktop 即可使用。

自定义数据存储位置

订阅数据默认保存在 ~/.rsshub-mcp/subscriptions.json。如需自定义位置，可设置环境变量：

{
  "mcpServers": {
    "rsshub": {
      "command": "npx",
      "args": ["rsshub-mcp"],
      "env": {
        "RSSHUB_INSTANCE": "http://localhost:1200",
        "RSSHUB_MCP_DATA_DIR": "/custom/path/to/data"
      }
    }
  }
}

可用工具

1. get_feed

获取 RSSHub 订阅源内容。支持两种模式：

模式 1：获取所有订阅（无参数）

  • 不传任何参数，自动获取所有已订阅源的内容

  • 返回聚合的订阅列表及其数据

模式 2：获取特定路由（传入 route 参数）

  • 获取指定路由的 RSS feed

参数：

  • route (可选): RSSHub 路由路径，例如 /bilibili/bangumi/media/9192。不提供时获取所有订阅

  • params (可选): 通用参数对象，如 { "limit": "10", "filter": "关键词" }

示例：

# 获取所有订阅的内容
获取我的所有订阅更新

# 获取特定路由
获取 Telegram 频道 awesomeRSSHub 的订阅内容
获取 B站番剧 9192 的更新
订阅 GitHub 仓库 anthropics/anthropic-sdk-python 的 releases

2. subscribe

将 RSS 源添加到订阅列表。

参数：

  • route (必需): 要订阅的 RSSHub 路由路径

  • name (可选): 订阅的自定义名称，便于识别

  • params (可选): 该订阅的默认参数，每次获取时自动应用

特性：

  • 自动检测重复订阅

  • 支持为订阅设置友好名称

  • 可预设默认参数（如过滤规则、条目限制）

  • 数据持久化保存在本地

示例：

订阅 B站番剧 /bilibili/bangumi/media/9192，命名为"我的追番"
添加 GitHub 仓库 /github/issue/vuejs/core 到订阅列表
订阅 /telegram/channel/awesomeRSSHub，限制10条

3. unsubscribe

从订阅列表中删除 RSS 源。

参数：

  • id (可选): 订阅的唯一 ID

  • route (可选): 要取消订阅的路由路径

说明： id 和 route 至少提供一个

示例：

取消订阅 /bilibili/bangumi/media/9192
删除订阅 ID 为 sub_xxx 的订阅

4. list_subscriptions

列出所有已保存的订阅。

参数： 无

返回信息：

  • 订阅 ID

  • 路由路径

  • 自定义名称

  • 默认参数

  • 创建时间

  • 完整 URL

示例：

显示我的所有订阅
列出订阅列表

5. search_routes

搜索 RSSHub 路由。自动从 RSSHub API 获取最新路由并支持模糊搜索。

参数：

  • query (必需): 搜索关键词，支持平台名称、路由名称、分类等

特性：

  • 从 RSSHub API 实时获取所有可用路由

  • 24小时本地缓存，提升响应速度

  • 支持按平台名称搜索（如 'bilibili'、'github'）

  • 支持按分类搜索（如 'social-media'、'programming'）

  • 支持按路由名称、描述模糊搜索

  • 最多返回 50 个匹配结果

示例：

搜索 bilibili 相关的路由
查找 github 的订阅方式
搜索 telegram 路由
查找 social-media 分类下的路由

使用示例

配置完成后，你可以在 Claude Desktop 中直接询问：

  1. 管理订阅：

    • "订阅 B站番剧 /bilibili/bangumi/media/9192，命名为'我的追番'"

    • "添加 GitHub 仓库 vuejs/core 的 issues 到订阅列表"

    • "显示我的所有订阅"

    • "取消订阅 /telegram/channel/awesomeRSSHub"

  2. 获取订阅内容：

    • "获取我的所有订阅更新" （一键获取所有订阅）

    • "帮我获取 Telegram 频道 awesomeRSSHub 的最新内容"

    • "查看 B站番剧 9192 的最新一集"

    • "查看 GitHub 仓库 vuejs/core 的最新 issues"

  3. 搜索路由：

    • "搜索 bilibili 相关的路由"

    • "查找 github 的订阅方式"

    • "有哪些 telegram 相关的路由？"

    • "搜索 social-media 分类的路由"

    • "如何订阅 Twitter 用户？"

    • "微博怎么订阅？"

RSSHub 路由说明

RSSHub 路由遵循以下格式：

/<平台>/<内容类型>/<参数>

例如：

  • /telegram/channel/awesomeRSSHub - Telegram 频道

  • /bilibili/user/dynamic/2267573 - B站用户动态

  • /github/issue/vuejs/core - GitHub Issues

  • /twitter/user/elonmusk - Twitter 用户推文

更多路由请访问 RSSHub 官方文档。

通用参数

RSSHub 支持以下通用参数：

  • limit: 限制返回条目数量，如 { "limit": "10" }

  • filter: 过滤标题和描述，如 { "filter": "关键词" }

  • filterout: 排除包含特定内容的条目

  • mode: 输出模式，如 fulltext 全文输出

使用示例：

获取 Telegram 频道的最新 10 条内容，路由是 /telegram/channel/awesomeRSSHub，限制 10 条

故障排除

常见问题

1. 502 Bad Gateway 错误

原因：

  • RSSHub 服务器负载过高

  • 上游网站（如 arxiv.org）暂时无法访问或响应超时

  • 网络连接问题

解决方案：

  • 稍后重试（这通常是临时性问题）

  • 使用其他 RSSHub 实例（自部署或其他公共实例）

  • 检查上游网站是否正常工作

2. 请求超时

原因：

  • 某些路由需要较长时间处理（超过 60 秒）

  • 网络连接慢

  • RSSHub 服务器响应慢

解决方案：

  • 稍后重试

  • 确认路由是否正确（使用 search_routes 工具）

  • 考虑使用自部署的 RSSHub 实例

3. 404 Not Found 错误

原因：

  • 路由不存在或路径错误

解决方案：

调试日志

MCP 服务器会输出详细的日志到标准错误输出（stderr），包括：

  • 请求的完整 URL

  • 请求耗时

  • 错误详情

可以通过 Claude Desktop 的日志查看这些信息（通常在 ~/Library/Logs/Claude/ 目录）。

配置建议

超时设置：

  • 默认超时：60 秒

  • 最大响应大小：50MB

  • 如果经常超时，建议自部署 RSSHub 实例

实例选择（按优先级排序）：

  1. 自部署实例（强烈推荐）

    • 配置：RSSHUB_INSTANCE=http://localhost:1200

    • 优点：最稳定、最快、无速率限制

    • 部署：5 分钟 Docker 一键部署

  2. 其他公共实例

  3. 默认公共实例 https://rsshub.app

    • 快速开始，但可能负载较高

    • 出现 502/503 错误时建议切换实例

配置方式：

  • 在 Claude Desktop 配置中设置 RSSHUB_INSTANCE 环境变量

支持的平台

包括但不限于：

  • 📱 社交媒体：Twitter/X、Telegram、微博、知乎、Reddit

  • 🎬 视频平台：Bilibili、YouTube

  • 💻 开发平台：GitHub、GitLab

  • 📰 新闻资讯：各类新闻网站

  • 🎮 游戏社区：Steam、Epic Games

  • 更多平台见 RSSHub 路由文档

相关链接

许可证

MIT

Available Tools

5 tools
get_feedA

Get RSSHub feed content. If route is provided, fetch specific feed. If no route is provided, fetch all subscribed feeds. Use RSSHUB_INSTANCE environment variable to configure custom instance.

ParametersJSON Schema
NameRequiredDescriptionDefault
routeNoOptional RSSHub route path, e.g., '/bilibili/bangumi/media/9192'. If omitted, returns all subscribed feeds.
paramsNoOptional general parameters, such as limit (number of items), filter (filtering rules), filterout (exclusion rules), etc.

TDQS

A3.6/5.0
Behavior2/5

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

No annotations exist, so the description bears full responsibility for disclosing behavior. It explains the route-dependent branches and environment variable configuration, but does not describe return format, error behavior, pagination, or side effects. For an unannotated tool, this is a notable gap in transparency.

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?

Three short sentences, each earning its place: first states the core function, second explains the conditional modes, third configures the instance. Front-loaded and free of redundant filler. Excellent conciseness.

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 no output schema and no annotations, the description should clarify what 'feed content' looks like, how feeds are presented, and any limitations. It covers the two operational modes but omits return value structure, error handling, and rate limits. Given the tool's moderate complexity, this incomplete context leaves the agent under-informed.

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 both 'route' and 'params' already described. The description mostly restates the route omission behavior already present in the schema and mentions the environment variable (not a parameter). It adds minimal extra meaning beyond the schema, which aligns with the baseline of 3 for full schema coverage.

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 tool's primary action ('Get RSSHub feed content') and immediately distinguishes between fetching a specific feed (with route) and fetching all subscribed feeds (without route). This is a specific verb+resource pairing that sets it apart from sibling tools like search_routes or list_subscriptions.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides explicit conditional guidance: 'If route is provided, fetch specific feed. If no route is provided, fetch all subscribed feeds.' This tells the agent exactly when to use each mode. It does not explicitly mention alternatives or situations to avoid, but the context is clear enough for basic selection.

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

list_subscriptionsA

List all RSS feed subscriptions. Shows all subscribed routes with their details.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

A3.8/5.0
Behavior3/5

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

With no annotations, the description carries the full burden. It implies a read-only operation ('List', 'Shows') and states that all subscriptions are returned, but does not disclose details like return format, ordering, or whether any side effects exist. It is adequate but lacks depth beyond the basic action.

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 two concise sentences that are front-loaded with the core action. Every word serves a purpose, and it avoids redundancy or extra fluff.

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 zero-parameter listing tool, the description is nearly complete: it states the action and scope (all subscriptions) and notes that details are included. However, it does not specify what those details are, which could be expected given no output schema. Still, the simplicity of the tool limits the need for more.

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?

The tool takes zero parameters, so the baseline is 4. The description does not need to add parameter meaning since there are none, and the empty schema already communicates this. The description's mention of 'all' aligns with the lack of parameters.

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 verb 'List' with the specific resource 'all RSS feed subscriptions', and further clarifies that it shows all subscribed routes with details. It distinguishes itself from siblings like get_feed (single feed) and search_routes (filtered search) by explicitly covering the full set without filters.

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?

The description does not provide any explicit guidance on when to use this tool versus alternatives. It does not mention that get_feed is for a single feed or that search_routes is for filtering, so the agent is left without direction on tool selection based on use case.

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

search_routesA

Search RSSHub routes. Support fuzzy search by keywords, can search platform names, route names, categories, etc. Automatically fetches latest routes from RSSHub API and caches them.

ParametersJSON Schema
NameRequiredDescriptionDefault
queryYesSearch keyword, supports platform names (e.g., 'bilibili', 'github'), categories (e.g., 'social-media'), route names, etc.

TDQS

A4.2/5.0
Behavior4/5

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

No annotations are provided, so the description carries the full burden. It discloses a notable behavior: 'Automatically fetches latest routes from RSSHub API and caches them,' which explains data freshness and potential cache use. It does not explicitly state read-only status, but 'search' strongly implies it.

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 two sentences, front-loaded with the core purpose, and every sentence adds value. It is concise and well-structured without redundancies.

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 one-parameter search tool with no output schema, the description covers the essential aspects: what it searches, how it works (fuzzy, caching), and data source. It could mention the return format, but this is a minor gap given the tool's simplicity.

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?

Schema coverage is 100% with a clear description of the 'query' parameter. The description adds 'fuzzy search' and enumerates searchable entities (platform names, route names, categories), going beyond the schema's examples and enriching parameter semantics.

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 'Search RSSHub routes' with a specific verb and resource. It further elaborates on fuzzy search and searchable fields, distinguishing it from siblings like get_feed or subscribe, which are about feed retrieval and subscription management.

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?

Usage is implied: use this tool to search for routes. However, there is no explicit guidance on when not to use it or when to prefer a sibling tool. For example, it doesn't mention that get_feed is for fetching a specific feed once a route is known.

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

subscribeA

Subscribe to an RSSHub feed. Add a route to your subscription list for easy access later.

ParametersJSON Schema
NameRequiredDescriptionDefault
nameNoOptional friendly name for this subscription, e.g., 'Bilibili Anime'
routeYesRSSHub route path to subscribe to, e.g., '/bilibili/bangumi/media/9192'
paramsNoOptional default parameters for this subscription

TDQS

A3.7/5.0
Behavior2/5

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

No annotations are provided, so the description carries the full burden. It states a basic mutation ('Subscribe') and the effect ('Add a route to your subscription list'), but it does not disclose potential side effects (e.g., whether an existing route is overwritten), authentication requirements, error behavior, or idempotency. This is a significant gap for a state-changing 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?

Two short sentences that each add value: the first defines the operation, the second gives context. No redundant phrases or filler, and the key information is front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description adequately conveys the purpose and outcome of subscribing, but lacks information about return values, error handling, or behavior on duplicate subscriptions. Since there is no output schema and no annotations, a bit more detail would be expected for full completeness, though the tool is relatively simple.

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 clear descriptions for 'route', 'name', and 'params'. The tool description itself adds no parameter-specific meaning beyond what the schema already provides, so the baseline score of 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?

The description clearly states the action ('Subscribe to an RSSHub feed') and the concrete outcome ('Add a route to your subscription list'). It distinguishes the tool from siblings like get_feed and search_routes by focusing on the persistent subscription action.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The phrase 'for easy access later' implies a use case: saving a route for future retrieval rather than immediate fetch. However, it does not explicitly contrast with alternatives such as get_feed or list_subscriptions, so it lacks full when/when-not guidance.

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

unsubscribeA

Unsubscribe from an RSSHub feed. Remove a subscription by ID or route.

ParametersJSON Schema
NameRequiredDescriptionDefault
idNoSubscription ID to remove
routeNoOr route path to unsubscribe from

TDQS

A3.5/5.0
Behavior2/5

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states the action and method, offering no information on side effects, reversibility, authentication, or return values, leaving critical operational traits undisclosed.

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 concise and front-loaded, but the two sentences partially repeat each other using synonyms ('feed' vs 'subscription'). It is still efficient and easy to parse, with no unnecessary verbosity.

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 no output schema or annotations, the description fails to explain return values, error behavior, or the constraint that exactly one of id/route must be provided. The schema's required: [] is misleading without clarification, making the description incomplete for correct invocation.

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 coverage is 100% with both parameters already described, so the baseline is 3. The description adds minimal extra meaning beyond the schema, and it doesn't clarify the one-of requirement implied by 'by ID or route' given that the schema marks both as optional.

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 uses a specific verb ('unsubscribe') and resource ('RSSHub feed'/'subscription'), making the tool's purpose unambiguous. It clearly distinguishes itself from siblings like subscribe and list_subscriptions by stating the removal action.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description clearly states the action and the method ('by ID or route'), providing clear context for when to use it. It doesn't explicitly name alternative tools, but the purpose is self-evident given the sibling set, so it slightly misses the full 'when-not' guidance.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 5 tool updatesv1.1.0
    • First observedget_feed
    • First observedlist_subscriptions
    • First observedsearch_routes
    • First observedsubscribe
    • First observedunsubscribe
Deploy Server
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A4/5.0

Scored across 5 tools

Disambiguation5/5

Each tool has a distinct purpose: fetching feed content, searching routes, and managing subscriptions (subscribe, unsubscribe, list). No overlapping functionality or ambiguity.

Naming Consistency4/5

Most tools follow a verb_noun pattern (get_feed, search_routes, list_subscriptions), but subscribe and unsubscribe are single verbs. This minor deviation is still predictable and readable.

Tool Count5/5

Five tools is well-scoped for a focused RSSHub server, covering discovery, retrieval, and subscription management without unnecessary extras.

Completeness5/5

The toolset covers the complete subscription lifecycle: discover routes, subscribe, list subscriptions, unsubscribe, and fetch feed content. No obvious gaps or dead ends.

Maintenance

ActivityInactive
ResponsivenessNo issues

Resources

Related MCP Connectors

  • hithereiamaliff-mcp-nextcloudOAuth
    ai.smithery

    A comprehensive Model Context Protocol (MCP) server that enables AI assistants to interact with yo…

    Cloud StorageFile SystemsWorkplace & Productivity
    238
  • mcpCOAuth
    com.wix

    A Model Context Protocol server for Wix AI tools

    Developer ToolsContent Management SystemsApp Automation
    216
  • TelnyxA
    com.telnyx.api

    The Telnyx MCP server is an official implementation of the Model Context Protocol that enables AI clients (like Claude Desktop, Cursor, and OpenAI Agents) to interact with Telnyx's telephony, messaging, and AI assistant APIs. It provides comprehensive capabilities including making and managing phone calls, sending SMS/MMS messages, purchasing and configuring phone numbers, creating AI assistants with custom instructions, managing cloud storage buckets, scraping and embedding website content, and handling integration secrets. The server exists as both a local implementation and a remotely hosted version, allowing developers to integrate real-world communication infrastructure directly into AI applications.

    CommunicationCloud PlatformsCloud Storage
    62
  • Apideck MCPA
    dev.apideck.mcp

    Model Context Protocol server for the Apideck Unified API. Connect any MCP-compatible agent framework to 100+ accounting systems, HRIS platforms, file storage providers, and more through one integration. More information https://www.apideck.com/mcp-server

    Developer Tools
    42

Related MCP Servers