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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is known. The description adds the behavioral scope: it aggregates current and near-term signals, and implicitly excludes multi-year/brand/executive depth by pointing to professional_intelligence. It does not describe output format, rate limits, or failure cases, but annotations reduce the burden.

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 is a single sentence with no filler; it front-loads the package label and then lists the included signal types. The list is somewhat dense and jargon-heavy, but every part contributes to understanding the tool's scope.

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?

For a tool with only 3 simple parameters, full schema coverage, no nested objects, and no output schema, the description gives enough context for an agent to select it and understand its aggregate nature. The phrase '节点与规则情感' is somewhat opaque, but the overall scope and the professional_intelligence alternative make the tool's boundaries clear.

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 100%, with keyword, geo, and timeframe each already described in the input schema. The tool description adds no param-specific meaning or constraints beyond that, so it stays at the baseline of 3.

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 clearly identifies the tool as a 't话题研究包' that aggregates multiple signal types: current resonance, search curve/momentum, related words, future signals, nodes, and rule sentiment. It names one sibling (professional_intelligence) as the alternative for more advanced needs, though it does not distinguish itself from other overlapping siblings like future_signals or related_queries.

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 explicitly tells the agent when NOT to use this tool: for multi-year lifecycle, forecast validation, brand entity analysis, or executive reports, use professional_intelligence. This provides a clear routing rule. However, it does not explicitly state when to choose analyze_topic over other siblings that cover individual components such as related_queries or future_signals.

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