Loading ToolBench
A comprehensive MCP server for parsing and analyzing RSS, Atom, and JSON feeds
Server has 7 tools with complete input schemas and descriptions. Naming follows verb_noun convention (rss_parse_feed, rss_search_feed, etc.). Descriptions are present and adequate (100-150 chars typical), exceeding the 20-char minimum. All tools are READ_ONLY with no state-modifying operations. However, output schemas are not documented in the source code, responses are inferred from implementation. Parameter descriptions are functional but lack actionable constraint details (e.g., 'ISO format: YYYY-MM-DD' is present for since_date, but most params lack format guidance). Error handling is not visible in the provided code. No tool annotations (readOnlyHint, etc.) despite all tools being read-only. Composition is sound, each tool has a single responsibility. Missing: output schema documentation, error recovery guidance, and per-parameter validation rules.
Compare multiple feeds side by side
Extract feed metadata without parsing all items
List feed categories with counts and feed names
List all available RSS feeds organized by category
Parse and retrieve items from RSS/Atom/JSON feeds
Search and filter feed items with advanced criteria
Validate feed structure and report issues
Output schemas not documented. Tool descriptions state what is returned (e.g., 'Parse and retrieve items') but do not specify the structure of the response object, field names, or types. LLMs cannot plan downstream tool calls or extract data without knowing response shape.
No tool annotations despite all tools being read-only. Tools should declare readOnlyHint=true to signal to agents that they are safe to call without side effects. This enables optimizations like caching and parallel execution.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 49 | <=2025-11-25 | v2 |
Error handling not visible in source. No evidence of try-catch blocks, error classification (retryable vs fatal), or recovery guidance. If a feed URL is invalid or unreachable, the LLM receives no actionable error message.
Parameter descriptions lack actionable constraint details. 'minLength', 'maximum', 'pattern' are in schema but not explained in description text. LLMs cannot read JSON Schema, they rely on description prose. E.g., 'since_date' has pattern but description should say 'ISO 8601 date (YYYY-MM-DD), e.g. 2024-01-15'.
rss_list_feeds and rss_list_categories have empty input schemas (no parameters). Descriptions do not explain what data structure is returned or how to filter/paginate results. If there are hundreds of feeds, how does the agent select a subset?