playlet-xiaohongshu-feed

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

With no annotations, the description carries the full burden and discloses the key behaviors: the 15:00 update schedule, the date-validity boundary, and an explicit prohibition on automatic date fallback ('禁止自动回退'). The no-fallback rule is especially valuable because it stops an agent from silently substituting an earlier date. It does not disclose return format or error behavior, but the critical operational traits are covered.

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?

Two sentences with the tool's purpose front-loaded before its constraints. Every clause earns its place. The second sentence is dense, packing three constraints into one run-on clause, which slightly harms readability, but there is no wasted text.

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?

The trickiest aspects for correct invocation — update cadence, date validity, and the no-fallback rule — are well covered, and both parameters are fully documented in the schema. However, with no output schema, the description does not explain the return format or what the response contains beyond 'notes sorted by interaction', and the instruction '无数据日期必须确认后再查' is ambiguous about what 'confirm' means and with whom.

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 coverage is 100%, so the baseline is 3. The description adds genuine meaning beyond the schema by stating the date parameter's allowed range (≤ latest data date), the confirmation requirement for no-data dates, and the no-fallback rule — none of which appear in the schema's parameter descriptions. The count parameter is already fully documented by the schema.

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 states a specific verb and resource: query Xiaohongshu short-drama notes by date, sorted by interaction volume. The qualifiers '短剧' (short drama), '互动量排序' (interaction sort), and the platform name distinguish it from most siblings implicitly, though it never explicitly contrasts itself with similar tools like playlet-douyin-feed or xiaohongshu-dailytop.

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 gives clear operational context: data updates daily at 15:00 for the previous day, dates must be ≤ the latest data date, and no-data dates require confirmation. However, it provides no guidance on when to choose this tool over the many similar siblings (playlet-bili-feed, playlet-douyin-feed, xiaohongshu-dailytop, xiaohongshu-ai-feed), so selection among alternatives is left to inference.

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