Loading ToolBench
RSS MCP demonstrates solid fundamentals with good naming conventions, complete parameter schemas, and clear descriptions. All 6 tools follow verb_noun naming patterns (list_, add_, remove_, enable_, get_, search_). Parameter descriptions are present and specific. However, output schemas are not formally documented, error handling lacks recovery guidance, and descriptions could be more LLM-optimized. The server shows decent adherence to patterns but gaps in production-grade polish prevent a higher score.
Add a new RSS source.
Enable or disable an RSS source.
Get articles from a specific RSS source.
List all RSS sources with optional filtering. Use this tool to get an overview of available RSS sources. This should be called first to understand what sources are available.
Remove an RSS source.
Search articles across RSS sources. This is the main tool for finding specific content. Use this when users ask about specific topics.
Output schemas not formally documented in tool docstrings. All 6 tools return structured data (inferred from code) but LLMs cannot reliably determine the shape, field names, and types of responses without explicit schema declarations. This forces LLMs to make assumptions or attempt trial-and-error calls.
Error handling and recovery guidance missing from tool descriptions. add_source validates inputs and checks duplicates in code, but these error cases (duplicate URL, invalid URL format, invalid name, invalid fetch_interval, fetch failure) are not documented in the docstring. LLMs cannot plan recovery steps without knowing failure modes.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 60 | <=2025-11-25 | v2 |
| 2026-03-09 | D | 57 | - | v1 |
Destructive tool (remove_source) lacks confirmation pattern and warning. Description does not flag this as destructive or suggest a dry-run/confirmation step. No mention of what happens to associated articles or how to recover from accidental deletion.
Descriptions are below LLM-optimization baseline for 3 of 6 tools. add_source (28 chars), remove_source (29 chars), and enable_source (47 chars) are too brief. Rubric baseline for good descriptions is 50 - 200 chars. Brief descriptions provide insufficient context for tool selection.
Pagination constraints not explicitly documented. get_feed_items and search_feeds support limit/offset but do not document maximum safe values, default behavior when limit exceeds API capacity, or whether pagination is exhaustible. This invites LLMs to request arbitrarily large result sets.
tags parameter uses free-form comma-separated strings instead of constrained input. Both add_source and list_sources accept tags as unvalidated strings. LLMs have no way to know valid tag values and may hallucinate tags. Should provide tag discovery mechanism or constrain to known set.
search_feeds 'query' parameter lacks format constraints. No indication of minimum/maximum length, regex patterns, or unsupported characters. LLMs may pass empty strings, extremely long queries, or special characters that break search.