Static source inference · medium confidence · detected: Logging
Deprecated protocol patterns detected
Summary
The server defines 11 tools with mostly clear names and basic descriptions. All tools are read-only (low risk) and follow verb_noun naming conventions (get_, search_). However, there are significant gaps: descriptions lack LLM-optimization guidance and context on when to use each tool; parameter descriptions are minimal and many lack type constraints; output schemas are not documented in the source code; and no error handling or recovery guidance is visible. Tool names are appropriate but descriptions do not explain dependencies, prerequisites, or relationships between tools. The schema definitions shown are minimal JSON Schema objects with types and basic descriptions, but lack examples of output structure, pagination details, or field documentation.
Tools (11)
get_all_namespacesread onlysource verified53/100
Handle get_all_namespaces tool call
get_categoriesread onlysource verified50/100
Handle get_categories tool call
get_categoryread onlysource verified52/100
Handle get_category tool call
get_feedread onlysource verified62/100
Handle get_feed tool call - Fetch actual RSS/Atom feed content from a RSSHub route
Minimal tool descriptions lack LLM-optimization guidance. Descriptions are under 20 chars in many cases (e.g., 'Handle get_all_namespaces tool call') and do not explain WHAT the tool does, WHEN to use it, or dependencies. LLMs cannot determine when to select these tools over alternatives.
Output schemas are not documented in the source code. The evaluation cannot verify what fields are returned by each tool, whether pagination is supported, or what IDs/references are included for tool chaining. This makes it impossible for LLMs to plan downstream calls.
Expand all tool descriptions to 50-200 characters, following the pattern: 'Fetches [resource] from RSSHub. Use this when you need to [specific use case]. Returns [key fields]. Requires [prerequisites if any].' Example: 'get_namespace: Fetches all routes within a namespace (e.g., \'github\', \'ithome\'). Returns route metadata including keys, descriptions, and parameters. Use search_namespaces first if you only have partial namespace names.'
Document complete output schemas for every tool. Include field names, types, and descriptions. Example for get_namespace: '{"routes": [{"key": "string", "title": "string", "description": "string", "parameters": [{"name": "string", "description": "string"}]}], "total": "integer", "namespace": "string"}'.
Add enum constraints to the 'format' parameter across all tools. Define explicitly: 'enum: ["json", "text"]' with descriptions explaining output differences (structured JSON for chaining vs human-readable text).
Document parameter relationships and dependencies in descriptions. Example for get_namespace: 'namespace (required): The namespace name to query. Obtain valid values from get_all_namespaces or search_namespaces. Examples: github, ithome, reddit.'
Add pagination support to list/search tools with documented parameters: 'limit (integer, 1-100, default 20): Max results per page. offset (integer, default 0): Skip N results. Returns total count to enable LLM pagination loops.'
Clarify 'search_namespaces' vs 'search_routes', both search but on different resources. Update descriptions: 'search_namespaces: Search namespace names and descriptions. Returns matching namespaces.' vs 'search_routes: Search specific route keys and metadata within namespaces. Returns matching routes with their parent namespace.'
Spec posture evidence
Inferred effective spec: <=2025-11-25.
Relies on Logging (deprecated) - log to stderr or use OpenTelemetry
Score history
Overall score trend
↑ 19 points across a rubric change (v1 → v2)
61/100
Scored
Grade
Overall
Spec posture
Rubric
2026-09-22
C
61
<=2025-11-25
v2
2026-03-09
F
42
-
v1
58/100
Handle get_route_detail tool call
search_namespacesread onlysource verified62/100
Handle search_namespaces tool call - More useful than listing all
Parameter descriptions are vague or missing constraints. Examples: 'format' appears in 7 tools but is described only as 'Output format, \'json\' or \'text\'' without explaining what format differences matter or when to use each. No enum constraints visible. 'query' and 'partial' parameters lack examples of expected input patterns.
No error handling guidance visible. Tool definitions show no documentation of what errors can occur, whether they are retryable, or how the LLM should recover. For example, 'namespace not found' vs 'invalid format' are not distinguished.
Tool composition and chaining not documented. get_namespace requires 'namespace' param but get_all_namespaces does not explain how to obtain valid namespace values. Similarly, search_routes returns results but the output schema is not visible, impossible to confirm if it returns 'route_key' needed by get_route_detail.
Pagination and result limits not documented. Tools like search_routes and get_all_namespaces lack documented limit/offset parameters or total count. Without pagination, large result sets risk overwhelming context windows.
Tool names lack disambiguation for related operations. Three separate 'get_*' tools for categories, radar rules, and routes could benefit from clearer descriptions to help LLMs choose. E.g., 'get_categories' vs 'search_routes', which searches categories vs routes is unclear from names alone.
get_categoriessearch_routesget_route_detail
Add error guidance for common failure modes: 'Namespace not found (404): Try search_namespaces with a partial name. Invalid format (400): format must be one of: json, text. Timeout (408): RSSHub instance is slow; retry after 2s.'
Document which tools support batch operations and which are single-item only. Example: 'suggest_route_keys returns multiple suggestions in one call; get_route_detail operates on a single route.'
Include chaining examples in descriptions to guide multi-step agent workflows. Example: 'To fetch RSS for a route: (1) call search_namespaces or get_all_namespaces to find namespace, (2) call get_namespace to list routes, (3) call get_route_detail for full route config, (4) call get_feed with the route path.'
Add idempotency guarantees to error handling. State: 'All tools are read-only and fully idempotent, safe to retry on timeout or 5xx errors without data loss.'