Loading ToolBench
MCP server for RSSHub - provides RSS feed access through Model Context Protocol
RSSHub MCP has 5 tools with verb-noun naming, but quality is uneven. All tools have descriptions (good baseline), and input schemas are present with type definitions. However, descriptions lack depth and specificity, they read as bare API documentation rather than LLM-optimized guidance. Parameters are documented but lack constraints (enums, ranges, min/max). Output schemas are NOT documented anywhere, critical for tool composition. Error handling is absent; the code returns raw axios errors without recovery guidance. STDIO transport is a hard cap at 50 for protocol readiness.
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.
List all RSS feed subscriptions. Shows all subscribed routes with their details.
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.
Subscribe to an RSSHub feed. Add a route to your subscription list for easy access later.
Unsubscribe from an RSSHub feed. Remove a subscription by ID or route.
Output schemas completely undocumented. LLMs cannot plan downstream tool calls or extract structured data from responses. get_feed, search_routes, subscribe, unsubscribe, list_subscriptions return data but schema is invisible to agents.
No error handling or recovery guidance. Code returns raw axios errors (e.g., network timeout, 404 from RSSHub API) with no context. LLMs cannot determine if error is retryable, user-fixable, or fatal. Example: fetchAllRoutes() throws if the API fails and cache is empty, with no actionable message.
Parameter constraints missing. 'params' field in get_feed uses additionalProperties: true with no enum or pattern. 'query' in search_routes has no length bounds. No min/max for limits. LLMs can pass invalid or absurd values (e.g., limit=999999).
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 49 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 0 | - | v1 |
Descriptions lack LLM-optimized context. 'Get RSSHub feed content.' does not explain WHEN to use get_feed vs search_routes+subscribe+get_feed pipeline. Descriptions under 100 chars for most tools; baseline for A-grade tools is 100+ chars with WHEN/WHY context.
No per-parameter descriptions for 'params' and 'id' fields. 'params' in get_feed has description but does not list valid RSSHub parameters (limit, filter, filterout), LLM must guess or hallucinate. 'id' in unsubscribe lacks any description of format or origin.
Destructive operations (subscribe, unsubscribe) lack confirmation/dry-run pattern. An agent can permanently remove a subscription with no warning or undo capability. No 'force' or 'confirm' parameter to gate destruction.
No pagination support. get_feed and search_routes (returns up to 50 routes) have no limit, offset, or cursor parameters. If an LLM needs all 500 available routes, it cannot iterate, search_routes caps results in code (slice(0, 50)) but tool has no way to request page 2.
unsubscribe requires either 'id' OR 'route' but neither is required in schema. If LLM provides both, behavior is undefined. If it provides neither, code will fail silently. Schema should enforce mutual exclusivity and describe both parameter formats.