Single tool (get_rss) with adequate naming and basic schema. Tool name 'get_rss' appropriately uses verb_noun pattern and is action-oriented. Input schema is present with three parameters, all with type definitions and descriptions. However, descriptions are minimal (10-50 characters), falling below the 50-200 character baseline for LLM-optimized descriptions. Output schema is not documented, the tool returns 'List[str]' but no structured output format is specified, forcing LLMs to infer the markdown text structure. Parameter descriptions lack detail on format constraints (date format documented as '2025-04-13' but no validation guidance). Error handling is absent, no recovery guidance when feed_name is invalid or fetch fails. The tool has actionable side effects (file export) but no dry-run or confirmation pattern.
Tool description is only 18 characters ('Fetch RSS feeds'), well below the 50-200 character baseline for LLM-optimized descriptions. Lacks context on when to use this tool, what it returns, and dependencies on feed configuration.
Output schema not documented. Tool returns 'List[str]' but LLMs have no visibility into the structure (markdown sections with feed titles, entry dates, summaries, links). Undocumented return format forces LLMs to guess at response structure.
'since' parameter description lacks format validation guidance. States 'e.g. "2025-04-13"' but no explicit statement that format is YYYY-MM-DD or what happens if invalid date is passed. Example values in descriptions may be reused literally by LLMs.
No error handling or recovery guidance. If feed_name not found, tool raises KeyError (caught in server.py but no user-friendly message returned). If feed fetch fails (network error, invalid XML), only a log entry is produced. LLMs receive no actionable error message.
Recommendations
Expand tool description to 100-150 characters explaining: what the tool does ('Fetch and return recent entries from RSS feeds'), when to use it ('Call this to retrieve articles from news sources, blogs, or other RSS-subscribed feeds'), and what it returns ('Formatted markdown text with feed titles, article titles, dates, summaries, and links').
Document output schema explicitly. Define return format as 'A single string containing markdown-formatted entries, grouped by feed title, with each entry showing: title (date), summary, and link. Most recent entries first.'
Replace example value in 'since' description with format constraint: 'Date in YYYY-MM-DD format (e.g., 2025-04-13). Only entries published on or after this date will be included. If invalid format, an error message will specify the required format.'
Replace example value in 'feed_name' description with guidance: 'Name of the feed group to fetch. Must match a feed name in the configured OPML file. Common values: Example (see server configuration for full list). If the name is not found, an error will list available feed names.'
Add error handling to the tool that returns structured error messages to the LLM: (1) Feed name not found → return 'Feed name "<name>" not found. Available feeds: <list>. Verify the feed name in your configuration.' (2) Feed fetch failure → return 'Failed to fetch feed from <url>: <reason>. Check that the feed URL is valid and accessible.' (3) Invalid date format → return 'Invalid date format "<input>". Expected format: YYYY-MM-DD (e.g., 2025-04-13).'
No confirmation or dry-run pattern for destructive action. 'export_result' parameter defaults to false, which is safe, but tool description does not warn that file export is a side effect or offer a way to preview output before writing.
'feed_name' parameter lacks guidance on available values. Description says 'Feed name (e.g. "Example")' but does not indicate whether Example is the only valid value, how to discover valid feeds, or what happens if invalid name is passed. LLMs cannot infer valid choices.
get_rss
Add a tool parameter or output note indicating the maximum number of entries returned per feed (currently hardcoded in config as 'max_entries_per_feed'). Document this limit so LLMs know results may be truncated.
Consider adding an optional 'limit' parameter to allow LLMs to cap total results (default to config value). This gives agents control over token usage when fetching from many feeds.
For export_result side effect, document in description: 'When export_result=true, output is also written to an MDX file in the output/ directory with naming format: rss-<feed_name>-<date>.mdx. This does not affect the returned text.'
Add a discovery tool or parameter to expose valid feed names. E.g., add a get_available_feeds() tool that returns the list of configured feed names. This prevents invalid feed_name guessing.