Loading ToolBench
MCP server for fetching, filtering, and searching RSS blog feeds
RSS Feeds MCP has 7 tools with consistent basic structure, but significant gaps in schema completeness, parameter descriptions, and error handling guidance. All tools have descriptions (10-60 chars, mostly adequate), and input parameters are defined with Zod schemas in code, but schema descriptions are sparse. Tool naming is clear and action-oriented (list_, add_, remove_, fetch_, search_), following the verb_noun pattern well. However, output schemas are not documented, pagination is missing from tools that return lists, and error responses lack recovery guidance. The server uses STDIO transport, which caps the protocol readiness score at 50 and limits remote accessibility.
Add a new RSS feed with optional category
Fetch latest blogs from all feeds with date range and limit
Fetch blogs from a specific category (seo, content, social, email, analytics, crm, news)
List all available feed categories for organizing content
List all configured RSS feeds with their categories
Remove an RSS feed by name
Search blogs by keyword across all feeds
Output schemas not documented. Tools return text/markdown responses but do not formally declare the structure of returned data (articles array with title, link, pubDate, source, category, summary fields). LLMs cannot plan downstream operations or extract specific fields without guessing the response structure.
No pagination support. fetch_blogs, fetch_by_category, and search_blogs accept a 'limit' parameter (default 20) but do not document total count, next_cursor, or page/offset mechanisms. If a user wants more than 20 articles, the tool offers no way to retrieve additional results without re-calling with different parameters. This violates paginated-result pattern.
Error handling lacks recovery guidance. When a feed fails to fetch (e.g., timeout, network error), the tool logs the error and returns an empty array. There is no error message returned to the LLM explaining what went wrong or what to do next. This violates the recovery-guide pattern.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 58 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 43 | - | v1 |
Parameter descriptions lack format constraints. The 'range' parameter in fetch_blogs, fetch_by_category, and search_blogs accepts strings like '1d', '7d', 'this_week', 'this_month', but the description does not enumerate valid values or clarify the format. LLMs may infer '2d', '14d', or 'last_month' are also valid, leading to parsing failures.
add_feed description mentions allowed categories but does not enforce them. The parameter is a free-form string with a suggestion ('category: seo, content, social, email, analytics, crm, news'), but the code does not validate against these values. An LLM may pass an arbitrary category, which will be stored and cause inconsistency.
STDIO transport limits remote accessibility. This server uses stdio-only transport, which means it cannot be accessed by hosted/cloud MCP clients or deployed as a service. This is a hard architectural limitation.
Duplicate or ambiguous tool names. fetch_blogs (all feeds) vs fetch_by_category (single category) vs search_blogs (keyword search) have similar names and overlapping functionality. The distinction is not immediately obvious from the names alone. Consider: list_articles_recent, list_articles_by_category, search_articles.
No confirmation or dry-run for destructive operations. remove_feed permanently deletes a feed from the configuration. There is no confirmation step or dry-run mode to prevent accidental deletion.