xiaohongshu-account-analyzer

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

Annotations are absent, so the description carries the full disclosure burden. It does reveal the output artifact (7-dimension report, exportable HTML) and implies multi-account capability via '多账号对比', which is genuinely useful. However, it stays silent on read/write nature, data source, failure behavior for invalid IDs, and what the seven dimensions actually are — all left to inference.

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?

A single compact sentence front-loads the core function (deep analysis + 7-dimension report + HTML export) before the trigger conditions. Each clause earns its place; only mild redundancy exists in the six overlapping trigger scenarios (账号诊断 ≈ 账号健康度评估), 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?

With no annotations, no output schema, and a schema whose descriptions are all tautologies, the description must carry the entire burden — and it covers purpose and triggers well. But it never explains how to construct a request (the roles of data/status/message/query_type/template_structure), what the seven dimensions are, or what happens on failure, so an agent would have to guess at most invocation details.

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?

Although schema coverage is nominally 100%, every parameter description is a tautology ('data'→'data', 'status'→'status', 'message'→'message'), so the schema adds zero meaning. The tool description hints at a few mappings (小红书号→userIds, 多账号对比→accounts/account_count, 可导出HTML→output_path) but leaves query_type, template_structure, data, status, and message completely opaque, and with 0 required parameters the agent cannot infer a correct call.

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+output: '深度拆解小红书账号' (deep-analyze Xiaohongshu accounts) producing '七维度量化评分诊断报告与可导出HTML' (a 7-dimension quantitative diagnostic report with exportable HTML). This is clearly account-level diagnosis, which separates it in scope from siblings like xiaohongshu-note-analyzer and xiaohongshu-search, though no sibling is explicitly named.

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 semicolon-separated second clause is an explicit trigger list: '当用户提供小红书号进行账号诊断、rednote分析、账号健康度评估、商业价值评估、多账号对比或制定优化策略时使用' — use when the user supplies a Xiaohongshu ID and asks for diagnosis, health, commercial value, multi-account comparison, or optimization strategy. This gives clear context for selection, but it never states when NOT to use it or names alternatives that handle adjacent tasks (e.g., note-level or similar-account analysis).

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