get_latest_rss

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden and largely succeeds: it discloses the all-sources default when feeds is omitted, the token-saving behavior of include_summary, max day/limit boundaries, and JSON return format. It doesn't mention error handling or rate limits, but for a read-only retrieval tool this is solid coverage.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description uses a clean docstring-style structure with summary, Args, Returns, and Examples sections. Every section earns its place, especially the parameter details that compensate for the schema's 0% coverage. It's slightly longer than minimal, but nothing is wasted.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the output schema exists to handle return value details, the description appropriately focuses on behavior: purpose, differentiation, all parameter semantics, and usage examples. Minor gaps like per-feed vs. total limit interpretation and error scenarios are acceptable for this moderate-complexity read tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must fully compensate, and it does. Each of the 4 parameters gets meaning, defaults, valid ranges (days max 30, limit max 500), and concrete feed ID examples (['hacker-news', '36kr']), plus the cost implication of include_summary. This exceeds what the bare schema provides.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific verb+resource: '获取最新的 RSS 订阅数据' (get latest RSS subscription data). It explicitly distinguishes from siblings by stating 'RSS 数据与热榜新闻分开存储' (RSS data is stored separately from hot news), which differentiates it from get_latest_news and get_trending_topics in the sibling list.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides clear context: '适合获取特定来源的最新内容' (suitable for getting latest content from specific sources) and the RSS-vs-hot-news separation implies when not to use this tool. However, it doesn't explicitly name alternative tools or provide formal exclusion criteria, falling short of the 5-level bar.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.