Loading ToolBench
Six tools with clear verb-noun naming and reasonable descriptions (avg 65 chars). All tools have input schemas with type definitions and parameter descriptions. However, output schemas are not documented, LLMs cannot predict what fields to expect from responses. Parameter descriptions lack actionable constraints (e.g., no enum for isRead, no format guidance for URLs). Error handling is absent from tool definitions. No tool annotations (readOnlyHint, destructiveHint, idempotentHint) despite clear risk classifications. Pagination is present (limit/offset) but total count and next_cursor are not documented. Overall: functional but incomplete for production LLM agents.
Get a single RSS entry by ID
Import RSS feeds from an OPML file
List RSS feed entries with filtering and pagination
List RSS feed subscriptions with pagination
Mark an RSS entry as read or unread
Refresh RSS feeds and fetch new entries
Output schemas not documented. LLMs cannot predict response structure, forcing them to guess what fields are returned and breaking downstream tool chaining.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint). Tools are classified with Risk labels (WRITE, READ_ONLY) but these are not exposed in the MCP schema, so clients cannot determine which tools are safe to retry or have side effects.
Boolean parameter 'isRead' in mark_entry_read lacks enum constraint and default value documentation. LLMs may pass null or string values; description should state 'defaults to true' explicitly.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 53 | <=2025-11-25 | v2 |
Pagination parameters (limit, offset) present but total count and next_cursor not documented. LLMs cannot determine if more results exist or how to fetch them efficiently.
No error recovery guidance in tool descriptions. If import_opml fails (malformed OPML, file not found), the description does not tell the LLM what to do next.